核心原因是浏览器未触发缓存：检查响应状态码是否为200等支持缓存的码、location是否准确匹配资源路径、是否被Disable cache或强制刷新绕过、Cache-Control是否被上游或add_header覆盖。
设置了 expires 却仍每次回源，通常不是配置没生效，而是缓存根本没被触发或被绕过了。核心原因在于：浏览器是否真正“信任”这个缓存，取决于响应状态码、资源路径匹配、请求方式以及服务端返回头的完整性。
检查响应状态码是否支持缓存
Nginx 的 expires 指令只对特定 HTTP 状态码生效：200、201、204、206、301、302、303、304、307。如果后端返回的是 4xx 或 5xx（比如 404 页面、502 网关错误），expires 完全不会写入响应头，浏览器自然不缓存。
- 用
curl -I https://yoursite.com/xxx.js查看实际响应头，确认状态码是 200 且包含Expires和Cache-Control - 特别注意：代理场景下（如
proxy_pass），若后端本身返回了Cache-Control: no-store或Set-Cookie，Nginx 默认不会覆盖，导致强缓存失效
确认 location 匹配是否准确
缓存策略必须落在真正服务静态资源的 location 块里。常见误配包括：
- 把
expires写在server块顶层，结果被更具体的location /api或location /覆盖 - 正则匹配写错：比如写成
location ~* \.js$，但实际文件路径是/static/js/app.a1b2c3.js—— 这没问题；但如果写成location ~* js$（少了个点），就可能误中/user?name=js这类动态接口 - Vue/React 等单页应用中，
location /用了try_files $uri $uri/ /index.html，但没单独为/index.html关闭缓存，导致 HTML 被长期缓存，后续 JS 更新后用户仍加载旧 HTML，浏览器实际发起的是新路径请求（如/dashboard），而该路径又命中了location /并回退到 index.html —— 此时返回的仍是缓存过的 HTML，造成“看似缓存生效，实则逻辑错乱”
排除浏览器主动绕过缓存的行为
以下情况即使响应头正确，浏览器也不会读缓存：
- 开发者工具 Network 面板勾选了 Disable cache（尤其本地调试时极易忽略）
- 用户手动按
Ctrl+F5或Cmd+Shift+R强制刷新，浏览器会带上Cache-Control: no-cache请求头，服务端返回 304 或 200，但不走本地磁盘缓存 - 地址栏直接输入 URL 回车，或点击链接跳转，才真正走 expires/max-age 缓存逻辑
- 某些浏览器（如 Safari）对
file://协议或 localhost 下的资源缓存策略更保守，建议用真实域名或127.0.0.1测试
验证 Cache-Control 是否被覆盖或冲突
expires 和 Cache-Control 共存时，后者优先级更高。如果配置中混用了多个 add_header，或上游代理（CDN、负载均衡）重写了响应头，可能导致：
-
expires 1y生效了，但某处又写了add_header Cache-Control "no-cache"，最终以 no-cache 为准 - 使用了
immutable，但浏览器版本太老（Chrome 49+、Firefox 49+ 支持），降级为普通 max-age 行为 - 后端应用（如 PHP、Node.js）自己输出了
Cache-Control头，Nginx 默认不会覆盖它，需用proxy_hide_header或fastcgi_hide_header配合add_header显式控制
