CSS自定义属性本身不触发重排重绘，但频繁JS修改（如touchmove中setProperty）会强制同步更新CSSOM；安全用法是:root定义+媒体查询切换，高风险是高频内联更新。
CSS自定义属性（--*）本身不触发重排重绘，但它的使用方式会间接影响性能——关键不在变量声明，而在变量被读写的位置和频率。
为什么var(--color)不会导致重排，但element.style.setProperty('--color', ...)可能卡顿
浏览器对CSS自定义属性的解析是惰性的：只要没被用于影响布局或绘制的属性（如 width、top、transform），就不会触发计算。但一旦你频繁通过 JS 修改 style.setProperty()，尤其在滚动或触摸事件中，就会强制浏览器同步更新 CSSOM 并重新匹配样式规则。
- ✅ 安全用法：
:root中定义 + 媒体查询切换（如暗色模式），浏览器只在媒体变化时批量重算 - ⚠️ 高风险用法：在
touchmove里每帧调用setProperty('--x', e.touches[0].clientX + 'px')，等同于高频内联样式更新 - ? 替代方案：若需响应式位移，优先用
transform: translateX(var(--x))+will-change: transform，让浏览器提前升层
var() 在动画中的实际开销：比硬编码略高，但可忽略
实测 Chrome DevTools 的 Rendering 面板显示，含 var(--opacity) 的 opacity 动画与直接写 opacity: 0.8 的 FPS 差异小于 1%（iOS Safari 17+、Android Chrome 125）。真正拖慢的是变量值来源：
- ❌ 每次动画帧都从
getComputedStyle(el).getPropertyValue('--opacity')读取 → 强制同步布局计算 - ✅ 提前缓存值：
const opacityVal = getComputedStyle(el).getPropertyValue('--opacity');，后续复用 - ✅ 更优：用
transition+ 类切换控制变量，避免 JS 干预动画过程
移动端特别要注意的三个陷阱
低端 Android WebView 和旧版 iOS Safari 对自定义属性的解析链更长，以下写法会放大延迟：
立即学习“前端免费学习笔记（深入）”；
- ? 多层 fallback 嵌套：
background: var(--bg, var(--fallback, #fff))—— 每层 fallback 都要尝试解析，建议最多一层 fallback - ? 在
@keyframes中大量使用var()（尤其配合 calc）：某些 Android 10 WebView 会退化为软件渲染 - ? 把自定义属性当“状态开关”滥用，例如
--is-active: 1+content: var(--is-active)触发伪元素重绘 —— 改用.btn--active类更轻量
最易被忽略的一点：自定义属性的性能优势只在“批量控制”时成立。单个按钮的颜色换肤用 var() 很优雅，但若每个列表项都独立 setProperty 一个 --item-index 再通过 nth-child 计算，就回到了低效选择器的老路。
