Nginx长期缓存需精准匹配带哈希的静态资源（如app.a1b2c3.js），用location ^~ /static/或正则匹配后缀，配expires max与add_header Cache-Control "public, immutable, max-age=315360000"；不带哈希资源慎用长期缓存，应设较短过期时间并配合版本化或CDN刷新；配置后须用curl和浏览器开发者工具验证响应头及缓存状态。
在 Linux 的 Nginx 中用 expires 设置长期缓存，关键不是单纯写“时间长”，而是匹配精准、策略合理、响应头完整——尤其要区分资源是否带哈希（如 app.a1b2c3.js），否则长期缓存反而导致用户看不到更新。
匹配带哈希的静态资源
只对内容稳定且 URL 随内容变化的文件启用长期缓存，比如构建后自动添加哈希的 JS/CSS/字体/图标：
- 用正则精准匹配后缀：
location ~* \.(js|css|woff2|ttf|eot|svg|png|jpg|gif)$ - 或更推荐前缀匹配静态目录：
location ^~ /static/（性能更高，避免正则开销） - 绝对不要写
location / { expires 1y; }，否则 HTML 和接口也会被缓存
设置 expires max 并补全 Cache-Control
expires max; 是最常用的长期缓存写法，它会让 Nginx 设置 Expires 为约 10 年后（HTTP 协议允许的最大值），同时生成 Cache-Control: max-age=315360000。但仅靠这个不够：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 必须加
add_header Cache-Control "public, immutable"; -
immutable告诉浏览器：该资源不会变更，F5 刷新也不发验证请求（跳过 If-None-Match 等），真正实现强缓存复用 - 注意：
add_header同一作用域内多次声明会覆盖，务必合并成一条，例如：add_header Cache-Control "public, immutable, max-age=315360000";
不带哈希的图片等资源慎用 long cache
像 logo.png 这类文件名固定、内容可能随时替换的资源，设 expires max 有风险：
- 建议改用
expires 30d;，并配add_header Cache-Control "public, max-age=2592000"; - 如果必须长期缓存，就得配套做文件名版本化（如
logo-v2.png）或走 CDN 缓存刷新流程 - 临时更新可设
expires 1h;，兼顾可控性与体验
配置后必须验证是否生效
改完不能直接上线，得确认响应头真实写入且浏览器识别正确：
- 先运行
nginx -t检查语法，再nginx -s reload重载 - 用
curl -I https://yoursite.com/app.abc123.js查看响应头，确认同时存在Expires和Cache-Control - 打开浏览器开发者工具 → Network → 刷新资源，状态码显示 200 (from memory cache) 或 200 (from disk cache) 才算成功
