styled-components 的样式注入不发生在每次渲染，而是在组件挂载或主题变更时检查并按需插入；动态插值绑定 React 渲染周期，导致运行时计算开销显著高于构建时处理的 CSS Modules。
styled-components 的样式注入发生在每次渲染吗？
不是每次渲染都重新注入，但每次组件挂载或主题变更时，styled-components 会检查是否已有对应哈希类名的样式规则；如果没有，就动态生成并插入 标签。这个过程本身不重放，但「判断 + 查找 + 插入」仍需运行时计算。
关键点在于：动态插值（如 ${props => props.primary ? 'blue' : 'gray'}）无法在构建时确定，必须等组件 render 阶段执行函数才能拿到结果，这就绑定了样式计算与 React 渲染生命周期。
- 首次挂载：生成类名、计算样式、插入
- 后续相同 props 渲染：复用已生成的类名（靠内部缓存）
- props 改变触发插值变化：查缓存 → 命中则复用，未命中则新建 → 缓存膨胀风险
- 主题 Provider 更新：所有依赖主题的组件强制 re-render，连带触发样式重算
为什么 CSS-in-JS 的运行时解析比 CSS Modules 慢？
CSS Modules 在构建时就把 button__root__abc123 这样的类名写死进 JS，运行时只做字符串拼接；而 styled-components 要在 JS 中解析模板字符串、执行插值函数、序列化对象、生成唯一哈希、查找 DOM 中是否存在对应 片段——这些全是 runtime 行为。
典型开销来源：
- 模板字符串解析：V8 需要将字符串内容转为 AST 并执行函数调用
- 哈希计算：对样式文本 + props 结构做
md5或类似哈希（v6 后改用更快算法，但仍存在） - DOM 查询：遍历
document.querySelectorAll('style[data-styled]')匹配已注入规则 - 样式去重逻辑：比较新旧规则是否完全一致，避免重复插入
实测中，一个含 5 个插值字段的 styled.div 组件，在低端安卓机上单次计算耗时可达 0.8–1.2ms —— 对动画帧（16ms）已构成压力。
哪些写法会让 styled-components 性能雪上加霜？
不是所有 styled 写法都一样重。以下模式会显著放大运行时负担：
- 在插值中调用非纯函数（如
new Date().getTime()、Math.random()），导致缓存失效 - 把整个 theme 对象传进插值：
color: ${props => props.theme.colors.primary}，而非提前解构${({ theme: { colors } }) => colors.primary} - 嵌套过深的媒体查询 + 插值组合，例如
@media (min-width: ${props => props.breakpoint}px) { ... } - 在组件内部反复调用
styled.xxx（比如循环里创建 styled 组件），造成大量闭包和样式实例
注意：css 辅助函数（如 css`${...}`）同样走运行时路径，它只是提取逻辑，不改变执行时机。
服务端渲染（SSR）时 styled-components 的瓶颈在哪？
SSR 本身不慢，但 styled-components 的 ServerStyleSheet 需要在 Node.js 环境中模拟浏览器样式注入行为：收集所有用到的样式规则、去重、序列化为字符串。问题在于：
- 无法预知客户端哪些 props 会触发哪些插值分支，所以得把所有可能生成的规则都收集进来
- theme 变更或高阶组件包裹下，收集范围容易失控（比如一个
withThemeHOC 导致子树全部被标记为“可能变化”） - 收集结果若过大，会导致 HTML payload 显著增加，抵消 SSR 的首屏优势
更隐蔽的问题是：如果客户端 hydration 时 props 与 SSR 时不一致（比如时间戳、用户权限字段），styled-components 会在浏览器端重新计算样式并 patch ，引发 FOUC 或布局抖动。
真正卡住性能的往往不是「用了 styled-components」，而是没意识到它的样式计算是 React render 的一部分——只要 render 有压力，样式计算就跟着卡。优化方向很明确：减少插值复杂度、拆分高更新频率的样式逻辑、必要时降级到 CSS Modules 或 Linaria 处理静态部分。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
