CSS变量不直接触发重排，但频繁读写或嵌套calc会加剧重绘和样式计算；var()本身安全，而getComputedStyle读取依赖变量的值会强制同步布局，循环中滥用将引发性能问题。
CSS变量本身不直接触发重排（reflow），但频繁读写或不当使用会显著放大重绘（repaint）和样式计算（Recalculate Style）开销——尤其在DOM节点多、选择器深、变量嵌套 calc 的场景下。
var()调用本身不触发重排，但getComputedStyle读取会强制同步布局
当你用 JavaScript 读取一个依赖 CSS 变量的计算值（比如 getComputedStyle(el).color），浏览器必须立即完成样式计算和布局，才能返回准确结果。这在循环中反复调用时，极易形成“强制同步布局”链。
- 错误写法：
for (let i = 0; i → 每次都触发完整样式计算 - 正确做法：先批量读取所有元素的
style或dataset，再统一计算；或用requestAnimationFrame节流 - 注意：
el.style.setProperty('--color', 'red')是异步的，不立刻触发重排；但紧跟着getComputedStyle就会卡住主线程
深层后代选择器 + CSS变量 = 样式匹配雪崩
浏览器从右往左匹配选择器，而 var() 值又需向上查找作用域链。当两者叠加，例如 .modal .header .title { color: var(--text-color); }，且页面有 200 个 .title 节点、每个都要回溯到最近的 --text-color 定义处，就会让 Recalculate Style 时间线陡增。
- Chrome DevTools Performance 面板中，这类问题常表现为「Layout」或「Update Layer Tree」前的长条「Recalculate Style」
- 避免写
body .content div p这类宽泛路径；改用 BEM 命名如.article__paragraph，并把变量定义在就近祖先上（比如.article { --text-color: #333; }） - 用
document.querySelector(':root').style.setProperty全局改变量时，所有用到它的选择器都会重新计算——不是逐个更新，而是全量重算
calc() 中嵌套 var() 会让样式引擎失去优化机会
CSS 引擎对纯数字 calc(16px + 8px) 可以静态折叠，但遇到 calc(var(--spacing) * 2) 就必须保留运行时计算逻辑，无法提前合并或缓存中间结果。
立即学习“前端免费学习笔记（深入）”；
- 实测显示：1000 个元素同时使用
width: calc(var(--base) * 1.5)，比用预计算好的width: var(--base-wide)多出约 12–18ms 的样式计算时间 - 高频动画场景（如拖拽、滚动）中，应避免在
transform或opacity相关属性里用var()+calc()组合；优先用 CSS 自定义属性配合will-change: transform提前升层 - 若必须动态缩放，建议用 JS 计算后写入
style.transform，而非靠 CSS 引擎实时解析
vanilla-extract / styled-components 等方案的“零运行时”不等于零开销
像 createThemeContract 这类编译时抽象，确实能减少客户端 var() 调用次数，但若主题切换时仍通过 assignInlineVars 批量写入 style 属性，就会绕过 CSSOM 缓存，导致每次更新都触发全量样式重计算。
- 生产环境务必启用
disableRuntimeStyles，让 vanilla-extract 把变量注入预生成的<style></style>标签，而非运行时 patch DOM - 不要在 React 组件 render 函数里反复调用
assignInlineVars；应提取为 memoized 样式对象，或改用 class 切换 - 全局变量定义在
:root是安全的，但若在 100+ 个组件内各自定义同名局部变量（如.card { --bg: white; }），会导致 CSSOM 存储冗余，内存占用上升
真正影响性能的从来不是 --color 这个符号本身，而是它被读、被查、被算、被传播的路径是否可控。变量越靠近使用点定义，层级越扁平，calc 越少嵌套，就越不容易掉进样式引擎的“最差匹配路径”。
