nginx需与浏览器、cdn、后端协同构建分层缓存体系：浏览器层用cache-control控制静态资源长期缓存与html校验；代理层通过proxy_cache_path、proxy_cache_valid等精细管控缓存粒度与容错；须对齐cdn及后端缓存策略，避免语义冲突；并借助purge模块或缓存标记实现主动失效管理。
要让Nginx真正成为缓存链路的“承上启下”枢纽，不能只盯着proxy_cache配几行就完事。它必须和浏览器、CDN、后端服务形成协同节奏——缓存不是堆得越多越好，而是每一层都该干好自己该干的事。
浏览器缓存：第一道轻量防线
浏览器缓存是离用户最近、成本最低的一层。Nginx可通过响应头直接控制它的行为，核心是Cache-Control和Expires。
-
静态资源（JS/CSS/图片）建议设为长期缓存，例如
Cache-Control: public, max-age=31536000（1年），配合内容哈希命名（如app.a1b2c3.js），确保更新时URL变化，避免旧缓存干扰 -
HTML页面通常不建议强缓存，可用
Cache-Control: no-cache或max-age=0，触发ETag或Last-Modified校验，既减少带宽又保证实时性 - 注意避免对含敏感信息的接口（如登录态API）设置公共缓存，应使用
private或no-store
Nginx 代理层缓存：关键中间缓冲区
这一层承担着“抗突发流量+减压后端”的双重任务，配置重点不在大小，而在粒度与淘汰逻辑。
- 用
proxy_cache_path定义独立SSD挂载路径，避免和系统盘争IO；设置levels=1:2 keys_zone=main:100m inactive=1h max_size=10g，兼顾查找效率与磁盘可控性 - 在
location块中用proxy_cache_valid按状态码分级缓存：比如200 302 10m，404 1m，避免错误响应被长期误存 - 启用
proxy_cache_lock on防止缓存失效瞬间的“缓存击穿”，同一key的多个并发请求只放行一个回源，其余等待结果 - 配合
proxy_cache_use_stale（如error timeout updating）提升容错能力，即使后端短暂不可用，仍可返回过期但可用的内容
与CDN及后端协同：避免缓存语义冲突
Nginx不是孤岛。它前面可能有CDN，后面连着Redis或应用服务，各层缓存策略必须对齐，否则会出现“CDN缓存了新数据，Nginx却返回旧版本”的错乱。
- 若上游已部署CDN，Nginx响应头中应避免覆盖CDN关心的缓存指令（如
Surrogate-Control），必要时用add_header补充而非覆盖 - 对需强一致性的接口（如订单详情），可在Nginx中用
proxy_cache_bypass $arg_nocache或检查请求头X-No-Cache，动态绕过缓存 - 后端应用返回的
Cache-Control若与Nginx本地策略冲突，可通过proxy_ignore_headers Cache-Control Expires Set-Cookie显式忽略，由Nginx统一决策
缓存失效与一致性：不能只靠过期时间
被动等待inactive或max_age过期太慢，尤其对高频更新的内容（如商品价格、活动页）。主动管理更可靠。
- 用
proxy_cache_purge模块（需编译启用）支持PURGE请求，通过特定规则清除匹配URI的缓存，例如：location ~ /purge(/.*)+proxy_cache_purge main $1 - 结合后端变更事件（如Canal监听MySQL binlog），触发对应缓存键的精准清理，而非全站flush
- 对无法精准定位的场景，可采用“缓存标记”方式：Nginx根据请求参数（如
version=v2）生成不同cache key，发布时切换参数值，自然实现灰度与切换
