直接换用linaria或vanilla-extract可消除80%+样式相关JS体积，因其零运行时架构将样式处理全移至构建期，彻底剔除解析、哈希、insertRule等运行时逻辑，而非依赖压缩或tree-shaking。
直接换用 linaria 或 vanilla-extract 能砍掉 80%+ 的样式相关 JS 体积——不是靠压缩，是让那部分运行时逻辑压根不打进 bundle。
为什么 CSS-in-JS 会让 bundle 明显变重
打包体积膨胀不是错觉。以 styled-components 为例，它把整套样式注入引擎（解析模板字符串、哈希计算、insertRule 封装、服务端渲染适配逻辑）全塞进 JS；@emotion/react 同样自带 css 函数、序列化器、缓存 Map 和 dev-only 校验代码。这些在构建后都变成真实字节，且无法 tree-shake。
- 一个空的
styled.div组件，引入的 runtime 代码约 12–15 KB（gzip 前） - 动态主题切换逻辑会额外带入颜色转换、媒体查询匹配等辅助函数
- Dev 模式下还包含 source map 映射、组件名推导、props 类型警告等调试代码，生产环境虽可删，但构建配置稍有疏漏就会残留
运行时样式生成真正吃 CPU 的地方
主线程卡顿往往不是因为“JS 多”，而是因为样式逻辑在每次 render 中同步执行、阻塞 layout：
-
css`color: ${props.color}`每次调用都要走一遍正则解析 + 字符串拼接 + 哈希计算 + 查重 + 插入 style 标签 - 滚动列表里 50 个
styled.li同时 re-render，就触发 50 次sheet.insertRule()，Chrome Performance 面板里能看到密集的 “Style” 子任务堆叠 - 强制同步布局：如果样式注入前读取了
offsetWidth或getComputedStyle，浏览器必须立刻 flush style 并 layout，放大开销
怎么确认你真被 runtime 样式拖慢了
别只看 Lighthouse 的 “Reduce unused JavaScript” 建议——那只是表象。重点查运行时行为：
- 打开 Chrome DevTools → Performance → 录制一次滚动或动画，筛选
insertRule、createTextNode、style.textContent =，看是否高频出现 - React DevTools 的 Profiler 里观察 commit 阶段耗时，若某组件
commit占比 >40%，且没做复杂计算，大概率是样式注入在扛锅 - 用
performance.mark()包住组件挂载逻辑，再加个performance.measure('style', 'mark-start', 'mark-end')，对比纯 DOM 组件的耗时差值
最常被忽略的一点：即使你用了 useMemo 缓存样式对象，只要底层库还在 runtime 注入，那套解析/哈希/插入流程就一个没少——缓存只省了 JS 对象创建，没动核心瓶颈。真正要动刀，得从构建时切口进去。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
