别让小疏忽拖垮整个系统
做后端开发的都知道，客户端发来的请求五花八门，有些看着正常，其实埋着雷。处理不当，轻则接口报错，重则服务器宕机。特别是在高并发场景下，一个没校验的参数可能直接把数据库打挂。
参数校验不能偷懒
用户提交表单时，前端可能做了验证，但别指望它能拦住所有非法数据。有人用 Postman 手动改请求，有人写脚本批量刷接口。比如注册接口，你以为手机号都是11位，结果来了个 "12345"，不校验直接入库，后面查数据全乱套。
常见做法是在服务端对关键字段做类型、长度、格式校验：
if (!phone || !/^1[3-9]\d{9}$/.test(phone)) {
return res.status(400).json({ error: '手机号格式错误' });
}防重请求得有手段
用户点提交按钮，半天没反应，再点一次——结果订单生成了两条。这种情况很常见。解决办法之一是加唯一请求ID（request id），客户端每次请求带上 token，服务端记录已处理的请求id，重复的直接拒绝。
也可以在前端按钮点击后禁用几秒，但这治标不治本，网络重传或程序重试照样会出问题。
别忽视超时设置
客户端请求某个接口，等了30秒才返回，可能是后端某个依赖服务卡住了。这时候不仅用户体验差，还可能耗尽服务器连接资源。建议在网关或服务层设置合理的超时时间，比如8秒，超过就断开。
同时要让客户端也配好超时，避免一直挂着连接：
// axios 示例
axios.get('/api/data', { timeout: 5000 }); // 5秒超时日志要够细，定位才快
线上出问题，第一反应是看日志。如果只记了“请求失败”，那基本没法查。最好记录客户端IP、User-Agent、请求路径、耗时、状态码，甚至完整参数（敏感信息脱敏）。
比如某个安卓用户频繁500错误，查日志发现全是特定版本APP在调一个废弃接口，立马就能定位是客户端没升级的问题。
限流保护不可少
正常用户每秒请求一两次，但爬虫或恶意脚本可能每秒几百次。不限流，服务器CPU瞬间拉满。可以用滑动窗口或令牌桶算法控制频率。
Nginx 配置示例：
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
location /api/ {
limit_req zone=api burst=20;
proxy_pass http://backend;
}这表示每个IP每秒最多10次请求，突发允许20次，超出的会被延迟或拒绝。
HTTPS 不只是加密
除了防止数据被窃听，HTTPS 还能减少中间代理篡改请求的风险。有些公共WiFi会注入脚本，修改返回内容，甚至偷偷加参数。强制HTTPS，配合 HSTS 头，能让客户端始终走安全通道。
同时注意时间戳校验，避免重放攻击——别人截获你的请求，改个时间又重新发一遍。