?v=1.0常无效因CDN/Nginx默认忽略查询参数、返回304协商缓存或统一设长时效；需配置etag off、expires -1等响应头，或改用内容哈希文件名配合immutable缓存。
直接用 v=1.0 这类查询参数让浏览器刷新缓存，看似简单，但实际效果不稳定——它不改变资源本身在 Nginx 和 CDN 眼中的“身份”，容易被中间层忽略。真正起效的关键，是让 URL 变化的同时，确保响应头策略与之匹配，并规避常见陷阱。
为什么 ?v=1.0 常常不起作用
浏览器通常会把 /js/app.js?v=1.0 和 /js/app.js?v=1.1 当作不同请求，但 CDN、反向代理或 Nginx 自身可能：
- 默认忽略查询参数（尤其未配置
proxy_cache_key包含$args） - 返回带
ETag或Last-Modified的响应，导致仍走 304 协商缓存 - 源站 Nginx 对
.js统一设了expires 1y，而没区分带参/不带参路径
让 ?v= 参数真正生效的 Nginx 配置
若必须使用版本参数（如 CMS 无法改构建流程），需在 location 中显式干预：
- 禁用协商缓存：添加
etag off; add_header Last-Modified ""; - 关闭强缓存或设短时效：
expires -1; add_header Cache-Control "no-cache, must-revalidate"; - 精准匹配带参静态资源（推荐）：
location ~* \.(js|css)(\?.*)?$ {
expires -1;
add_header Cache-Control "no-cache";
etag off;
add_header Last-Modified "";
}
比 ?v= 更可靠的做法：用内容哈希替代版本号
前端构建工具（Webpack/Vite）自动生成带哈希的文件名，例如 app.a1b2c3d4.js，配合以下 Nginx 配置：
- 对哈希文件启用长期缓存：
location ~* \.(js|css)$ { expires 1y; add_header Cache-Control "public, immutable"; } - 确保 HTML 中引用路径已更新（构建时自动完成）
- 无需改 Nginx 缓存逻辑，也不依赖浏览器对参数的理解差异
验证是否真的刷新成功
别只看 HTML 源码里有没有 v=1.1，重点检查浏览器开发者工具 Network 面板：
- Status 是 200（不是 304）
- Response Headers 中
Cache-Control和Expires符合预期 - 响应体内容与你刚部署的文件一致（可复制对比）
- 用无痕窗口或清除浏览器缓存再测，排除本地残留影响
