根本不是变量本身慢，而是浏览器需为所有依赖它的节点重新执行样式计算→布局→绘制；大面积继承变量使每次更新触发千级节点重算，尤其嵌套calc()或深层选择器时性能陡降。
为什么改一个 --color-primary 就让整页卡顿
根本不是变量本身慢，而是浏览器必须为**所有依赖它的计算样式节点**重新走一遍样式计算流程。比如 --color-primary 同时被用在 color、border-color、box-shadow 和 background 上，且这些样式散落在几百个元素中——每次调用 style.setProperty()，浏览器就得批量标记这些节点“样式已失效”，接着触发 Recalculate Style → Layout → Paint 连锁反应。
实操中容易误判：看到 DevTools 的 Paint Flashing 只闪了一小块，就以为没影响；其实真正耗时的是 Styles 面板里 “Recalculate Style” 时间飙升、节点数破千——这才是抖动根源。
document.documentElement.style.setProperty() 触发重绘的隐性条件
单纯执行这行代码不会自动重绘，它只改了变量值；是否重绘，取决于有没有元素的**计算样式被标记为无效**。而这个标记动作，往往由以下行为间接触发：
- 修改了某个父级元素的
class或data-theme属性（推荐） - 强制读取
getComputedStyle(el).color（会同步触发样式计算） - 操作一个影响布局的属性，如
body.style.transform = 'translateZ(0)'（触发重排） - 在
requestAnimationFrame回调里读写，但不保证下一帧就重绘
最稳妥的路径是：改变量 + 切 data-theme 类，让 CSS 引擎主动重解析整套规则，而不是靠 JS 硬推。
立即学习“前端免费学习笔记（深入）”；
大面积继承的变量为何比局部变量更危险
当 :root 定义的 --bg-color 被 200 个组件通过 background-color: var(--bg-color) 继承，它就不再是“一个颜色”，而是一个**全局信号源**。JS 每次更新，浏览器必须检查这 200 个组件是否仍匹配该变量引用链——尤其当变量还嵌套了 calc() 或跨层引用（如 --bg: var(--bg-base)），匹配成本指数级上升。
可验证方式：
- 打开 Elements 面板，点任意使用该变量的元素 → Styles → Computed → 搜索
--bg-color→ 看 “Used by” 列是否列出大量节点 - Performance 面板录制一次切换，重点看 “Recalculate Style” 的 Self Time 是否 > 5ms
- 避免把交互态变量（如 hover 色、加载态缩放）和主题色混用同一个变量名
真正容易被忽略的性能瓶颈不在 JS，而在 CSS 规则本身
很多人花时间优化 setProperty 调用频次，却没意识到：如果 CSS 里写了 [data-theme="dark"] .header .nav ul li a:hover { color: var(--text-accent); } 这种 4 层嵌套选择器，浏览器每次主题切换都要对整个 DOM 树做右向匹配；而换成 .nav-link--hover-dark { color: var(--text-accent); }，开销直接下降一个数量级。
变量只是载体，真正决定性能的是：你用什么选择器把它“接”进渲染流水线。
