Nginx缓存API响应可显著提升稳定性。需筛选低频更新高访问、无用户上下文、幂等只读、后端耗时>200ms的接口；合理配置缓存路径、key、有效期；启用stale兜底与后台刷新；加强监控与主动清除。
直接用 Nginx 缓存 API 响应，是提升 API 服务器稳定性的最有效手段之一。它不依赖后端代码改动，却能显著降低突发流量对数据库、业务逻辑层的冲击，让系统在高并发下仍保持可预期的响应能力。
明确哪些 API 适合缓存
不是所有接口都该进缓存。重点筛选满足以下条件的接口：
- 低频更新、高访问量：如城市天气预报（每小时更新）、商品类目列表（数小时不变）、用户等级规则说明页；
-
无强用户上下文：不依赖 Cookie、Authorization 头中动态 token 的身份信息，或已通过
proxy_cache_key显式排除敏感字段； - 幂等且无副作用：只读 GET 请求，不触发下单、扣库存等写操作；
- 后端耗时明显：单次响应 > 200ms，尤其涉及多表 JOIN、远程调用或复杂计算的接口。
配置关键缓存参数，避免“缓存污染”
错误的缓存策略比不缓存更危险。必须控制好三个核心维度：
-
缓存位置与容量：用
proxy_cache_path指定独立磁盘路径，设置max_size防止占满空间，inactive=10m自动清理长期未访问条目； -
缓存键设计：默认 key 包含 URL + 参数 + Host，若需区分登录态，可加入
$http_authorization；若要统一缓存（如忽略分页参数），则自定义proxy_cache_key，例如：proxy_cache_key "$scheme$request_method$host$request_uri"; -
缓存有效期：不要只靠后端返回的
Cache-Control。用proxy_cache_valid主动覆盖，例如：proxy_cache_valid 200 302 5m;—— 对成功响应强制缓存 5 分钟，确保即使后端临时不可用，Nginx 仍可返回 stale 内容（配合proxy_cache_use_stale）。
启用 stale 缓存兜底机制
当后端宕机或超时时，Nginx 可继续提供“过期但可用”的缓存内容，这对稳定性至关重要：
- 添加
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504; - 搭配
proxy_cache_background_update on;，让 Nginx 在后台悄悄刷新过期缓存，前端始终拿到可用数据； - 必要时加
add_header X-Cache-Status $upstream_cache_status;方便定位是否命中 stale。
监控与主动失效策略
缓存不能一配了之，必须可观测、可干预：
- 开启
log_format cache '$remote_addr - $upstream_cache_status ...';，在 access log 中记录 HIT/MISS/STALE； - 对需要实时更新的资源（如某商品价格变更），不依赖过期时间，而是用
proxy_cache_purge模块配合特定请求头或路径主动清除，例如：location ~ /purge(/.*) { allow 127.0.0.1; proxy_cache_purge my_cache "$scheme$request_method$host$1"; } - 定期检查
proxy_cache_path目录实际占用和文件数量，防止 inode 耗尽。
