css-in-js 运行时变慢因动态生成样式、插入标签、哈希计算等均在主线程执行，频繁渲染时 cpu 压力大；改用 linaria 或 vanilla-extract 等 zero-runtime 工具在构建时生成静态 css 可消除该开销。
为什么 CSS-in-JS 在运行时会变慢
CSS-in-JS（比如 styled-components 或 @emotion/react）在组件渲染时动态生成样式字符串、插入 <style></style> 标签、做哈希计算和规则去重——这些全在浏览器主线程里做。尤其在列表滚动、频繁 re-render 的场景下，useEffect 里插样式、css 函数反复解析模板字符串，CPU 时间很容易被吃掉。
典型表现：React DevTools 显示 commit 阶段耗时突增；Lighthouse 报“减少非必要样式计算”；移动端滑动卡顿明显。
用 CSS 工具链提前生成静态 CSS
核心思路是把原本 runtime 做的事，挪到 build time：用工具把 JS 中的样式逻辑“编译”成普通 CSS 文件，再像传统样式一样加载。不是放弃 CSS-in-JS 的开发体验，而是换种方式落地。
实操建议：
- 选支持“zero-runtime”模式的库：
linaria（Babel 插件 + 静态分析）、vanilla-extract（TypeScript +build时生成 CSS 文件） - 避免在
vanilla-extract的style调用里写闭包或依赖 props 的动态值——它只认编译期可求值的表达式 -
linaria不支持import动态路径或变量名拼接（如import(`./${theme}.css`)），否则构建会失败 - 生成的 CSS 文件需确保被 Webpack/Vite 正确纳入打包，检查 output 是否含
.css，别漏了extract-css-chunks-webpack-plugin或 Vite 的css.codeSplit配置
如何验证是否真消除了 runtime 开销
不能只看 bundle size 降了没——关键是看运行时有没有还调用 insertRule、createTextNode 或大量正则匹配 CSS 字符串。
排查方法：
- 打开 Chrome DevTools → Performance → 录制一次交互 → 搜索
insertRule或style，如果几乎不出现，说明 runtime 注入已移除 - 断点打在
styled-components的injectStyles或@emotion/sheet的insert方法上，确认它们不再被调用 - 对比前后帧耗时：用
performance.mark()包住组件 mount 过程，看style相关子任务是否从 commit 阶段消失
vanilla-extract 和 linaria 的关键差异点
两者都走 build-time 路线，但设计哲学和约束完全不同。
vanilla-extract 更激进：
- 样式必须定义在
.css.ts文件里，不能写在 React 组件内部 - 主题切换靠
defineTheme+ 多份生成的 CSS 文件，不是 runtime 切 class - 支持 TypeScript 类型推导，但不支持任意 JS 表达式——比如
color: theme.colors[mode]可以，但color: mode === 'dark' ? 'black' : 'white'不行（除非mode是 const）
linaria 更贴近原有习惯：
- 允许写在组件文件里，语法几乎和
styled-components一致 - 但所有样式值必须是字面量或编译期常量，
useState、useContext的值不能直接进css模板 - 不支持 CSS Custom Properties 的 runtime 动态赋值（
--color: {color}会报错）
真正难处理的是那些看似“静态”、实则依赖运行时环境的样式逻辑——比如根据 window.matchMedia 或 getComputedStyle 结果生成的规则。这类没法被任何 build-time 工具捕获，得手动拆出来用媒体查询或 class 控制。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
