根本原因是css-in-js运行时注入机制与hmr存在天然冲突：变量值被固化在js执行上下文中，而非css层，改:root或外部css文件后，js中已求值的var(--x)不会自动刷新；linaria等零运行时方案在开发模式下仍依赖runtime fallback，绕过hmr链路，导致变量更新失效。
CSS变量在CSS-in-JS框架中热更新失效，根本原因不是变量本身有问题，而是CSS-in-JS的运行时注入机制与HMR（热模块替换）存在天然冲突——变量值被固化在JS执行上下文中，而非CSS层，改了:root或外部CSS文件，JS里缓存的var(--x)解析结果不会自动刷新。
为什么CSS-in-JS里改:root变量不触发样式更新
CSS-in-JS（如styled-components、Emotion）在组件首次渲染时，会把var(--primary)这类表达式立即求值并转成硬编码值（比如#3b82f6），之后就不再监听CSS变量变化。即使你用DevTools改了:root里的--primary，JS层已无感知。
- DevTools修改
:root只影响原生CSS规则，对JS生成的style标签无效 - 组件重渲染时若没显式读取新变量值（如
props.theme.color），样式不会更新 - 某些库（如older Emotion）甚至把
var()当字符串原样塞进style属性，浏览器根本不解析
Webpack/Vite中CSS变量+CSS-in-JS混合使用时的HMR断点
构建工具能热更CSS文件，但无法通知CSS-in-JS库“变量变了”，导致两边状态脱节。
- Webpack的
style-loader热更的是<style></style>标签内容，而styled-components维护的是独立的CSSOM注入逻辑 - Vite的HMR默认只触发JS模块更新，
import './theme.css'变更不会触发styled.div重新计算 - 若变量定义在SCSS中再通过
@import引入，且未配置liveSassCompiler.includeItems，改变量文件根本不会触发重编译
Linaria等零运行时方案为何也卡在热更新上
Linaria虽把CSS抽离为真实.css文件，但开发时仍需runtime fallback——而这个fallback机制常绕过HMR链路。
- Vite用户必须设
dev: false才启用zero-runtime，但开发模式下dev: true强制走JS注入，改CSS变量毫无反应 - Webpack中若
linaria/loader位置错（比如排在css-loader之后），变量会被当成普通CSS模块处理，失去静态分析能力 - 最终生成的
.css文件路径若没被HTML正确<link>引用，浏览器加载的仍是旧缓存版本
真正要让CSS变量在CSS-in-JS环境里热更新，得放弃“改变量自动生效”的幻想——要么把变量收口为JS常量（const colors = { primary: '#3b82f6' }），要么彻底切到纯CSS工作流，否则每次改变量都得手动刷新页面。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
