CSS变量能绕过CSS-in-JS运行时样式生成，因其将动态部分交由浏览器原生CSS引擎处理，仅需轻量DOM操作更新变量值，避免了字符串拼接、类名哈希重算和style标签更新等开销。
为什么CSS变量能绕过CSS-in-JS的运行时样式生成
CSS变量本身不触发任何运行时样式计算——它只是把动态部分“卸载”到浏览器原生的CSS引擎里，而CSS-in-JS库（如 styled-components 或 @emotion/react）原本要干的那套事：拼字符串、查重、调用 insertRule、维护 sheet 缓存……全被跳过了。
关键在于：变量赋值（element.style.setProperty('--color', value)）是轻量 DOM 操作；而变量消费（color: var(--color)）由浏览器在渲染管线中自动 resolve，不占用 JS 主线程。
- 不用在每次 render 时重新生成整条 CSS 规则，只改一个属性值
- 避免了
styled组件内部因 props 变化导致的类名哈希重算和 style 标签更新 - 配合
will-change: var(--target)还能提前触发 GPU 层提升，进一步减少重绘开销
Linaria / vanilla-extract 中怎么安全用 CSS 变量
Linaria 和 vanilla-extract 本身禁止运行时插值，但允许你在静态 CSS 中声明变量，并在 JS 中仅控制其值——这正是它们推荐的“动态样式”解法。
常见错误是试图在 css 模板字面量里写 color: ${props => props.color}，这会直接让构建失败。正确做法是：
立即学习“前端免费学习笔记（深入）”；
- 在
css块里写color: var(--fg-color, #333)，提供 fallback - 用
ref.current.style.setProperty('--fg-color', color)在组件内更新（或用useEffect+useState驱动） - 确保变量名是合法标识符（不能含空格、特殊符号），且命名空间清晰（如
--btn-bg而非--bg）
注意：Linaria 不会校验变量是否被设置，也不会报错——如果忘了 setProperty，就只能看到 fallback 值。
什么时候不该用 CSS 变量替代插值
不是所有动态样式都适合塞进 CSS 变量。以下场景容易踩坑：
- 需要基于变量做媒体查询判断（
@media (prefers-color-scheme: dark)无法读取--color） - 动画关键帧里依赖 JS 计算的中间值（
@keyframes不支持var()动态解析） - 服务端渲染（SSR）中初始值未同步注入
style标签，导致 FOUC 或样式错乱 - 大量变量集中在一个元素上（>10 个），可能触发 Chrome 的
styleRecalc性能警告
这类情况更适合回归传统方案：用 className 切换预编译好的主题类，或改用 StyleX 的 stylex.props 这类带类型约束的零 runtime 动态方案。
CSS变量 + 预编译方案的实际性能差异
在滚动列表（如 TaskList.tsx）中，每项都根据 priority 渲染不同背景色：
- 用
styled.div`background: ${p => p.priority === 'high' ? 'red' : 'blue'}`→ 每次 rerender 都触发 insertRule + 类名重哈希 - 改用
css`background: var(--item-bg)`+el.style.setProperty('--item-bg', color)→ 仅一次 DOM 属性更新，无样式表操作
实测 Chrome Performance 面板中 commit 阶段耗时下降 60%+，尤其在低端安卓机上帧率更稳定。但前提是：变量必须复用（不要每个元素都设独立变量），且 fallback 值合理——否则浏览器仍要回退到 JS 计算 fallback。
真正难的不是写对那一行 setProperty，而是判断哪些状态值得暴露为变量、哪些该收进预编译类里。这个边界，得看具体组件的更新频率和样式复杂度，没法一刀切。
