加?v=参数不能可靠解决CSS缓存问题，因其易被构建工具剥离、CDN忽略或服务端未纳入缓存键；推荐使用文件名contenthash，由构建工具自动重写HTML和@import中的引用，确保内容变则文件名变、浏览器强制更新。
加 ?v= 参数能绕过缓存，但不是所有写法都有效——关键看参数是否出现在最终请求的 URL 中，以及服务端或 CDN 是否真正按它区分缓存。
为什么 ?v= 有时不起作用
浏览器确实会把 style.css?v=1.0.1 和 style.css?v=1.0.2 当作两个资源，但前提是这个 URL 真正发到了服务器。常见失效原因包括：
- 构建工具（如 Vite 的
build.rollupOptions或 Webpack 的url-loader）默认剥离查询参数，导致 HTML 里写的?v=xxx在产物中被删掉了 - Nginx 或 CDN 配置了
proxy_cache_key但没包含$args，结果?v=1和?v=2被当成同一个缓存键 - CDN 后台开了 “Ignore query string”（比如 Cloudflare 免费版默认勾选），直接忽略所有
?后内容 - 参数加在了错误位置：比如写成
style.css#main?v=1，#后面的内容根本不会发给服务器
?v= 值该用什么
值本身没有语义，但选错会影响缓存效率和可维护性：
-
?v=1.2.3：适合发布流程严格的项目，但必须确保每次 CSS 变更都同步升级版本号，否则无效 -
?t=1716459180（时间戳）：构建时用Math.floor(Date.now() / 1000)注入，简单可靠；但每次构建都不同，彻底废掉长期缓存 -
?hash=abc123：推荐用文件内容哈希（如 Webpack 的[contenthash]），内容不变则参数不变，兼顾精准与复用 - 绝对不要用
?v=Math.random()或?v=new Date().getTime()：前端运行时生成，每个用户、每次打开都不同，CDN 无法缓存，带宽浪费严重
手动加 ?v= 时必须检查的三件事
如果你是手写 HTML 或后端模板直出，而不是用构建工具自动注入，务必确认：
立即学习“前端免费学习笔记（深入）”；
-
<link rel="stylesheet" href="css/main.css?v=20260523">中的路径必须和静态服务器上真实文件路径完全一致（比如不能是/static/css/main.css却写成css/main.css） - 服务端不需要识别
v=，但要能正常返回main.css文件内容——Nginx/Vercel/Netlify 默认就支持，无需额外配置 - 如果用了
@import，比如main.css里写了@import "base.css";，那base.css的 URL 也得单独加?v=，否则它仍走旧缓存
比 ?v= 更稳的替代方案
当项目已接入 Webpack/Vite/Rollup，优先用文件名哈希而非查询参数：
- Webpack：配
MiniCssExtractPlugin.filename = '[name].[contenthash:8].css'，再让HtmlWebpackPlugin自动注入新文件名 - Vite：确保
build.rollupOptions.output.assetFileNames包含[hash]占位符，例如'assets/[name].[hash].css' - 关键点：CSS 文件名变了，HTML 中的
href和@import路径都必须同步更新——漏掉任意一个，就会 404 或样式丢失
文件名哈希不依赖查询参数，天然避开 CDN 忽略 ? 的问题，但要求构建流程完整闭环。很多团队卡在“HTML 更新了，@import 没更新”这一步，结果上线后部分样式白屏。
