Nginx 的 rewrite 指令不能解决缓存穿透问题，因其仅重写 URL 而无法识别恶意请求或资源真实性；静态资源缓存问题本质是更新失败，应采用哈希命名+Cache-Control强缓存方案。
直接用 Nginx 的 rewrite 指令做“静态资源版本动态重定向”并不能真正解决缓存穿透问题，反而容易引入歧义和额外风险。原因在于：缓存穿透（cache penetration）特指查询**根本不存在的数据**（如非法 ID、恶意构造的 key），导致请求绕过缓存直击数据库；而静态资源（JS/CSS/图片等）本身是确定存在的文件，其缓存问题属于**缓存失效或命中不一致**，更准确的说法是“静态资源缓存更新失败”或“缓存未及时刷新”，不是穿透。
为什么 rewrite 不适合解决缓存穿透
rewrite 是 URL 重写机制，用于改变请求路径并内部跳转（或外部重定向）。它无法识别“该资源是否真实存在”或“该请求是否恶意”。例如：
- 你配置
rewrite ^/js/app.js$ /js/app.[hash].js last;，但若构建后哈希变了，旧 HTML 仍引用app.js，Nginx 可以重写，但前提是你要手动维护这个映射表——这不可持续； - 如果用户直接请求一个根本不存在的路径如
/js/xxx.js，rewrite 无法判断这是误输、攻击还是真缺失，盲目重写可能暴露内部结构或返回错误内容； - rewrite 不参与缓存决策，也不影响浏览器或 CDN 对响应头（如
Cache-Control）的处理，对“穿透”毫无拦截能力。
真正该做的：用哈希命名 + Cache-Control 组合防控
静态资源的“缓存更新失败”问题，核心解法是让每个资源文件名自带内容指纹，再配合强缓存策略。Nginx 在其中只负责正确透传响应头和高效服务文件，而非靠 rewrite 补救。
-
构建时生成带哈希的文件名：Vite/webpack 默认在 production 模式下输出
index.abc123.js、main.def456.css等，HTML 中自动引用对应哈希名； -
HTML 不硬编码静态路径，而是由构建工具注入：避免手写
<script src="/js/app.js"></script>，改用模板变量或构建后替换； -
Nginx 配置静态文件强缓存：对已知类型（.js/.css/.png 等）设置长期缓存，例如：
location ~* \.(js|css|png|jpg|gif|ico)$ {<br> expires 1y;<br> add_header Cache-Control "public, immutable";<br>}
其中immutable告诉浏览器：只要 URL 不变，内容绝不会变，无需发条件请求； -
确保 HTML 本身不被过度缓存：HTML 应禁用长缓存（如
Cache-Control: no-cache或短时间max-age=60），保证用户总能拿到最新版 HTML，从而加载最新哈希资源。
如果非要“动态适配旧链接”，可考虑安全的 fallback 方式
极少数遗留场景需兼容无哈希的老 URL（如运营页面外链），可用 try_files 安全降级，而非 rewrite：
- 配置
try_files $uri $uri/ /index.html;仅适用于单页应用（SPA）的前端路由回退； - 对资源文件，可写明确 fallback 规则，例如：
location /js/ {<br> try_files $uri @hash_fallback;<br>}<br>location @hash_fallback {<br> rewrite ^/js/(.*)\.js$ /js/$1.*\.js break;<br> # ❌ 不推荐：正则模糊匹配易出错，且无法精准定位唯一哈希文件<br>}
这种做法实际不可靠，因为一个文件名可能对应多个哈希变体，Nginx 无法做内容比对。
所以，与其花精力在 rewrite 上兜底，不如确保构建流程稳定输出哈希文件、HTML 引用准确、Nginx 正确设置缓存头。这才是轻量、可靠、可维护的方案。
