css变量未生效主因是浏览器未触发重绘，需通过devtools的computed面板查“used by”确认是否被引用；高频更新或作用域过宽会导致recalculate style耗时激增，应按语义拆分作用域并节流。
JS 修改了 setProperty 却没看到样式变化，大概率不是“没生效”，而是浏览器压根没触发重绘——根本原因常出在变量继承范围过大、更新太勤，或变量压根没被任何计算样式实际引用。
怎么确认 CSS 变量真被用了？别靠猜，看 Computed
打开 Chrome DevTools → Elements 面板 → 选中任意一个你预期会变的元素 → 切到 Styles 标签页 → 展开 Computed → 搜索你的变量名（比如 --theme-color）→ 看“Used by”列：
- 如果显示 “0 matches”，说明这个变量压根没参与任何样式计算，
setProperty再多次也没用 - 如果只列出 1–2 个元素，但你改的是
:root，那很可能是选择器写错了（比如漏了.card类，或写了div.card却实际是section.card） - 如果列出上百项，恭喜，你已踩中“大面积继承”雷区——接下来不是调 JS，而是要砍作用域
为什么 setProperty 后页面“卡住”不动？Recalculate Style 时间爆表
打开 Performance 面板 → 录制一次变量更新操作（比如点按钮触发 document.documentElement.style.setProperty）→ 停止后重点看：
-
Recalculate Style耗时是否 > 5ms？节点数是否 > 1000？ - 有没有紧跟着一大片
Layout和Paint？ - 如果有，说明浏览器正在为所有依赖该变量的元素重新走样式计算流程，不是“没刷新”，是“来不及刷”
这时加再多 requestAnimationFrame 都没用——得先减少无效计算节点。
高频更新变量必须拆域：:root 不是垃圾桶
把所有变量都塞进 :root，等于让每个 DOM 节点都监听同一广播。实际只需按更新节奏和语义切分：
- 主题色类（如
--color-primary）→ 改名成--theme-color-primary，只在初始化时设一次 - 交互态类（如 hover 色、选中边框）→ 提到组件级作用域，比如
.btn:hover { --ui-state-color: #ef4444; } - 动画缩放因子 → 独立为
--anim-scale，且只在带is-animated类的容器下生效：.card.is-animated { --anim-scale: 1.2; } - 绝对不要用同一个变量既控制
font-size（触发布局），又控制color（仅重绘）
节流比重写更管用：1 秒 1 次和 60 次，渲染负担差 3 个数量级
尤其在 scroll、mousemove 里直接调 setProperty，等于每帧都在 invalidating 样式树：
- 用
throttle包一层，确保每秒最多更新 1–2 次（lodash.throttle(fn, 500)） - 对滚动场景，优先用
IntersectionObserver批量判断可视区域后再统一更新，而非监听scroll - 非视觉用途的变量（比如仅用于
data-属性或埋点逻辑），立刻移出 CSS 变量体系，改用纯 JS 对象管理
真正容易被忽略的，是变量本身不消耗性能，消耗性能的是浏览器每次都要重新判定“哪些元素的样式因此失效”。作用域越宽、复用越杂、更新越密，这个判定成本就越高——它不报错，只是悄悄拖慢整页响应。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
