css变量性能优于usestate控制样式，因其修改不触发react重渲染，仅标记自定义属性变更并惰性求值，避免reconciliation与commit开销，适合高频交互与全局主题切换。
因为 CSS 变量能绕过 React 渲染周期直接触发布局更新，而 useState 控制样式必然引发组件重渲染——后者在高频交互（如拖拽、滚动、主题切换）中容易成为性能瓶颈。
React State 控制样式会强制重渲染
每次调用 setState，React 都会触发整个组件（或子树）的 reconciliation 和 commit 流程，即使只改一个颜色值。
- 哪怕只是
setBgColor('#1f2937')，也会走完整生命周期：diff props → 构建新 VDOM → patch DOM → 触发 layout/paint - 如果该组件被
React.memo包裹，但 style 对象引用未变（比如没用useMemo），反而可能漏更新 - 子组件若依赖父组件传入的 style 值，却没做 memo 或 deps 检查，就会出现“状态变了但样式不动”的假死现象
CSS 变量修改不触发 React 渲染
通过 element.style.setProperty('--bg', value) 或 JSX 的 style={{ '--bg': value }} 更新变量，浏览器只标记该自定义属性变更，样式计算延迟到下一帧或强制读取时才发生。
-
document.documentElement.style.setProperty('--theme', 'dark')→ 全局变量更新，所有background-color: var(--theme)的元素自动重绘，无需任何组件 rerender - 配合
transition: background-color 0.3s时，动画由浏览器合成线程驱动，比 JS 控制的setState+useEffect插值更平滑 - 伪元素（
::before）、继承属性（color）、@media查询结果都能响应变量变化，而内联style无法影响它们
变量作用域与组件通信方式根本不同
State 是单向数据流，CSS 变量是层叠式作用域——这决定了它们适合解决的问题类型完全不同。
- 想让深色模式同时影响按钮背景、文字颜色、边框圆角？用
:root { --color-bg: #1f2937; --color-text: #f9fafb; }一处定义，全站生效；用 State 得层层透传 props，或依赖 Context，极易断裂 - 组件库（如 Ant Design）暴露
--el-color-primary，使用者只需在父容器设style={{ '--el-color-primary': '#3b82f6' }}，内部所有子组件立刻响应——State 做不到这种“穿透式”定制 - SCSS 模块中写
color: var(--nav-item-color, #007bff)，外部可通过变量覆盖，而不需破坏模块作用域；用 State 则必须把所有可配置项都设计成 props，接口爆炸
容易踩的坑：不是所有场景都适合换
CSS 变量不是万能替代品，它和 State 各有边界。混用时最常栽在三个地方：
- 变量名拼错或漏写双横线：写成
'primary-color'而不是'--primary-color'，浏览器静默忽略，DevTools 里也看不到 - 数学运算不套
calc()：比如width: var(--gap) * 2无效，必须写成width: calc(var(--gap) * 2) - 动态值没做 fallback：JS 中读取
getComputedStyle(el).getPropertyValue('--size')返回空字符串而非undefined，需要.trim()后判断
真正关键的不是“该不该用”，而是明确变量属于设计系统层（CSS 变量）还是业务逻辑层（State）——前者管“长什么样”，后者管“正在做什么”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
