核心是避免缓存集体失效与回源集中爆发：nginx通过proxy_cache_lock+background_update实现串行回源与后台更新，配合stale容错、合理cache_key及轻量拦截，降低后端压力。
核心不是“拦住请求”，而是让缓存不集体失效、让回源不集中爆发——Nginx 层能做的，是把穿透压力从“并发打库”压成“串行回源+兜底返回”，同时杜绝无效请求直达后端。
用 proxy_cache_lock + background_update 实现串行回源
当缓存过期，多个相同请求同时到达时，默认会全部穿透。启用锁机制可只放行第一个，其余等待或返回旧缓存：
- 必须配齐三项：proxy_cache_path（定义缓存区和共享内存）、proxy_cache（启用缓存）、proxy_cache_lock on
- 搭配 proxy_cache_background_update on：首个请求回源时，后台悄悄拉新数据，避免后续请求再等
- 设合理超时：proxy_cache_lock_timeout 5s（太短→放弃锁直接穿透；太长→用户卡顿）
- 确保 key 足够粗粒度，例如 proxy_cache_key "$scheme$host$uri";，避免因参数不同导致每个请求都算独立 key，锁失效
启用 stale 容错，不让用户等、也不让数据库扛
即使锁生效，首个请求也可能超时或失败。此时不能让其他请求干等或全量降级，而应允许返回“勉强能用”的响应：
- proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504 updating;——只要上游出问题或正在更新，就返回旧缓存
- 加上 proxy_cache_valid 200 302 5m; 明确有效期，否则“过期”无意义，“stale”也无从触发
- 用 add_header X-Cache-Status $upstream_cache_status; 实时验证是否真返回了 STALE 或 HIT
收紧 cache_key，消灭“伪高频”
看起来是“大量请求穿透”，实际常因 cache_key 过细，造成大量冷 key 并发失效：
- 禁用易变字段：不要包含 $args、$cookie_、$http_authorization
- 推荐写法：proxy_cache_key "$scheme$host$request_uri";（若需忽略?t=、v=等参数，先用 set 或 map 标准化 $request_uri）
- 若接口本身是路径型（如 /api/user/123），用 $scheme$host$uri 更稳妥，彻底剥离 query
加一层轻量拦截，过滤明显非法请求
真正压垮数据库的，往往不是正常查询，而是恶意遍历或空值扫描：
- 对高频无效 ID（如 -1、0、999999999）或枚举特征（1000001, 1000002…）做简单校验，Nginx 中可用 Lua 或 map + return 404
- 开启 limit_req 对异常 IP 临时限流，例如每秒最多 5 次，防爬虫式穿透
- 对确认不存在的数据，上游应返回明确空响应，并由 Nginx 缓存为逻辑空值（如 {"code":200,"data":null}），过期时间设为 60–120 秒，防反复穿透
