要实现200响应的长期静态化缓存，须综合资源类型、响应头控制与缓存键设计：带哈希名的静态资源可设1年缓存，HTML限10–30秒并启用stale机制，API建议60秒；需忽略Cache-Control、Set-Cookie等干扰头；缓存键须包含版本标识（如查询参数），且必须配置proxy_cache_path、proxy_cache及proxy_pass。
要让 200 响应真正实现长期静态化缓存，不能只写一句 proxy_cache_valid 200 1y 就完事——必须配合资源特性、响应头控制和缓存键设计，否则 Nginx 会因后端头或默认策略直接拒绝缓存。
区分资源类型，按需设长周期
不是所有 200 都适合长期缓存。关键看文件是否带版本标识：
-
JS/CSS/图片/字体等带哈希名的资源（如
app.8a3f2d.js）：内容不变则 URL 不变，可放心设为proxy_cache_valid 200 1y; -
普通 HTML 页面（如
/index.html）：即使返回 200，也建议限制在10s或30s，并搭配proxy_cache_use_stale error timeout updating;提升可用性 -
API 接口类 200（如
/api/user）：通常不建议长期缓存，应单独 location 中覆盖为proxy_cache_valid 200 60s;
绕过上游响应头干扰
Nginx 默认尊重后端返回的 Cache-Control: no-cache、Set-Cookie 等头，哪怕你写了 1y 也无效。需主动忽略：
- 加
proxy_ignore_headers Cache-Control Expires Set-Cookie;强制启用缓存 - 若后端仅对静态资源错误注入
Set-Cookie，可更精准地忽略：proxy_ignore_headers Set-Cookie; - 注意副作用：忽略
Set-Cookie后，若缓存键未包含用户维度（如$cookie_sessionid），可能造成用户内容错乱
确保缓存键能区分不同版本
长期缓存的前提是“相同 URL = 相同内容”。若资源通过查询参数更新（如 style.css?v=2.1），需显式把参数纳入缓存键：
- 默认
proxy_cache_key $scheme$proxy_host$request_uri;已包含$request_uri，支持带参 URL - 若需更精细控制（比如忽略跟踪参数
utm_source），可自定义：proxy_cache_key "$scheme$proxy_host$uri$is_args$args";并配合map过滤无关参数
配套基础配置不可少
proxy_cache_valid 单独存在完全无效，以下三项必须同时满足：
- 全局已定义缓存区：
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=static_cache:50m max_size=2g; - 当前 location 启用该区：
proxy_cache static_cache; - 有
proxy_pass指向后端，且后端能返回稳定 200
