静态资源长效缓存的关键是分层控制、文件名哈希化与服务端协同：带哈希的js/css/图片设“public, max-age=31536000, immutable”，html禁用长效缓存，nginx proxy_cache配7天有效期，open_file_cache优化小文件元数据访问。
静态资源长效缓存的关键不是盲目设长 max-age，而是分层控制 + 文件名可变性 + 服务端协同。浏览器缓存设一年没问题，前提是 JS/CSS/图片带哈希（如 app.f3a8b2.js），否则更新后用户无法感知。
浏览器端：用 Cache-Control 实现真正长效
优先使用 add_header Cache-Control，比 expires 更精准、兼容性更好：
-
带哈希的资源（推荐）：直接设为
"public, max-age=31536000, immutable"—— 1 年不重验，immutable告诉浏览器“内容绝不会变”，跳过If-None-Match校验 -
无哈希但稳定的资源（如字体、通用图标）：设
"public, max-age=31536000"，不加immutable，保留基础校验能力 -
HTML 文件：必须避免长效缓存，设
"no-cache, must-revalidate"或"max-age=0"，确保每次打开都拉取最新版本
服务端磁盘缓存：proxy_cache 配合长效策略
Nginx 自身磁盘缓存不是为了替代浏览器缓存，而是减少文件系统反复 open/read 开销。配置要点：
- 在
http块定义缓存区：proxy_cache_path /var/cache/nginx/static_cache levels=1:2 keys_zone=static_cache:50m max_size=5g inactive=30d use_temp_path=off; -
inactive=30d表示 30 天未被访问就自动清理，适合长期不变的静态资源 - 在匹配静态后缀的
location中启用：proxy_cache static_cache; proxy_cache_valid 200 302 7d;（响应成功时缓存 7 天即可，足够覆盖高频访问） - 务必加
add_header X-Cache-Status $upstream_cache_status;，方便验证是否命中 HIT
文件系统级优化：open_file_cache 减少元数据开销
这是常被忽略但对高并发小文件（如图标、字体、CSS 分片）至关重要的底层加速：
-
open_file_cache max=10000 inactive=60s;—— 缓存最多 1 万个文件元数据，60 秒内未再访问即淘汰 -
open_file_cache_valid 30s;—— 每 30 秒主动检查一次缓存条目有效性（重新 stat） -
open_file_cache_min_uses 2;—— 同一文件在 60 秒内至少被访问 2 次才进缓存，防爬虫污染 -
open_file_cache_errors on;—— 把 404、权限拒绝等错误也缓存，避免反复触发系统调用
更新与失效：长效缓存不等于不可更新
长效 ≠ 锁死。要保障更新及时生效，核心靠两点：
-
构建时生成内容哈希文件名（如 Webpack 的
[contenthash]）—— URL 变了，浏览器自然请求新资源，旧缓存自动作废 -
必要时手动清理：若无法改名，需编译安装
ngx_cache_purge模块，通过proxy_cache_purge接口清除指定路径缓存 - 不建议依赖
proxy_cache_revalidate来“保新鲜”——它只在缓存快过期时回源校验，仍存在窗口期；长效场景下，哈希机制更可靠
