根本原因是CDN或Nginx未将?v=参数纳入缓存键，导致不同版本URL被当作同一资源缓存；最稳解法是使用contenthash生成带哈希的CSS文件名（如theme.a1b2c3.css），并由构建工具自动注入HTML引用，配合Cache-Control: public, max-age=31536000强缓存。
CDN 缓存不更新 CSS 变量（比如 :root 里定义的 --primary-color）根本不是变量本身的问题，而是你引用的 CSS 文件被 CDN 当成旧资源复用了——变量改了，但文件 URL 没变，缓存就锁死了。
为什么加 ?v= 参数对 CSS 变量无效
你改了 theme.css 里的 --bg-color: #f0f0f0，HTML 中写成 <link href="theme.css?v=2.0.1">，但用户还是看到旧色。这不是变量语法问题，是 CDN 或 Nginx 没把 ?v= 算进缓存键：
- Cloudflare 免费计划默认勾选「Ignore query string」，
theme.css?v=2.0.1和theme.css?v=2.0.2被当成同一个 key 缓存 - Nginx 的
proxy_cache_key如果没包含$args，例如写成"$scheme$request_method$host$request_uri"（漏了$args），也会忽略查询参数 - 更隐蔽的是：你构建时没生成新文件，只是手动改了
v=值，结果 CDN 加载的仍是旧文件内容
用 contenthash 替代 ?v= 是最稳的解法
靠 URL 参数区分版本，在生产环境容易断链；让文件名本身带哈希，才能确保“URL 变 → 缓存必破”。Webpack/Vite 默认支持，关键在配置和引用同步：
- Vite 项目确保
build.rollupOptions.output.entryFileNames启用了contenthash，例如[name].[hash:8].js，CSS 同理 - 构建后输出类似
theme.a1b2c3d4.css，HTML 中的<link>必须由构建工具自动注入该带哈希的路径，不能手写或模板硬编码 - 配套服务端响应头设为
Cache-Control: public, max-age=31536000，让 CDN 和浏览器都敢长期缓存——因为文件名变了，天然不冲突
如果必须用 ?v=（如 CMS 不支持改 HTML 引用）
那就得从三处同时收紧控制，否则任意一环松动都会失效：
立即学习“前端免费学习笔记（深入）”；
- CDN 控制台关闭「忽略查询参数」，Cloudflare 在 Cache Rules 里关掉，腾讯云/阿里云找「查询字符串缓存策略」设为「包含」
- Nginx 配置确认
proxy_cache_key完整包含$args：proxy_cache_key "$scheme$request_method$host$request_uri$args"; - 服务端响应头不要设过长缓存，
Cache-Control: public, max-age=3600更安全；避免max-age=31536000+v=组合，等于给缓存上双保险锁
真正麻烦的从来不是怎么写变量，而是部署链路上哪一层悄悄复用了旧文件——查 X-Cache: HIT 和 Age 响应头，比反复改 CSS 更快定位问题。
