事件背景与动机
情境与驱动因素
在现代前端框架中，Emotion 等 CSS-in-JS 库曾经成为快速搭建 UI 的重要工具之一。它们将样式与组件高度绑定，便于实现筛选、条件渲染与动态主题，使开发循环更短、迭代更快。与此同时，运行时注入、样式作用域和命名冲突管理等能力，也让团队在复杂应用中获得可观的灵活性。然而，随着应用规模扩大，运行成本与打包体积逐渐成为需要直面的现实挑战。
例如，在一个拥有大量页面的设计系统中，使用 CSS-in-JS 能确保设计令牌的一致性，但也带来额外的运行时解析与注入成本，以及对服务器端渲染（SSR）的额外负担。Emotion 团队在评估后意识到，长期目标可能需要以更可控的静态样式为基础，以提升首屏性能和可预测性。
// Emotion CSS-in-JS 示例
import { css } from '@emotion/css';
const button = css`padding: 12px 24px;border-radius: 6px;background: var(--color-primary);color: white;
`;
<button className={button}>提交</button>
上述示例强调了一个核心点：样式与组件的耦合可以提升开发效率，但在某些情境下也放大了运行时负担和调试成本。Emotion 团队在内部评估后，逐步探讨如何在保持一致性的前提下，降低运行时开销、提升可预测性，并考虑对现有设计系统的顺滑迁移路径。
对前端架构的直接影响
性能与渲染管线的变化
当一个团队决定减少对 CSS-in-JS 的依赖时，样式注入时机与渲染路径的变化成为核心。移除或弱化运行时样式生成，往往会让构建过程偏向静态 CSS 的产出，从而使 首屏渲染更可预测、缓存命中更高，并降低服务器端渲染（SSR）的复杂度。
与此同时，样式优先级与冲突诊断的成本也会发生转移。无需在客户端执行大量样式组合时，开发者可能更容易追踪到特定组件的样式来源，但也需要在设计系统级别确保变量和令牌的统一性，以避免分散的风格定义造成不一致。
// 传统 CSS-in-JS 的运行时开销对比示意
// 情感样式注入时，浏览器需要在运行时计算、注入与缓存
// 静态 CSS 的情况下，这部分工作在构建阶段完成
一个关键结论是：渲染管线的简化与静态化相辅相成，但也要求在设计系统层面进行更严格的风格令牌管理和命名规范，以确保跨项目的一致性。
设计系统与主题的演化
设计系统的一个核心需求是可预测的主题切换和令牌复用。去除 CSS-in-JS 的实现后，设计令牌通常需要通过 CSS 变量或静态样式表来暴露，以确保跨组件的一致性仍然可控。这样做的直接影响是，主题更便捷地跨应用共享，但也要求对全局样式秩序有更清晰的治理。
下面是一个常见的主题变量实现示例，它通过 CSS 变量在根节点暴露主题色，便于后续通过简单的切换实现主题变换：
:root {--color-primary: #3b82f6;--color-text: #1f2937;
}
[data-theme="dark"] {--color-primary: #60a5fa;--color-text: #e5e7eb;
}
通过这样的机制，主题的可扩展性与可维护性提升，但需要确保全局变量的命名与作用域不会造成冲突，尤其在大型应用和跨团队协作中。
现有代码库的迁移挑战
已有大量使用 CSS-in-JS 的代码库，在迁移到更传统的样式体系时，重构成本与回归风险成为现实挑战。需要对组件边界、样式覆盖、主题依赖做系统化的梳理，确保 UI 在迁移过程中的可用性不被破坏。
常见的迁移路径包括将组件样式迁移到 CSS Modules、静态 CSS 文件或 CSS 变量驱动的样式体系，并逐步降低对运行时注入的依赖，以实现更稳定的构建与缓存策略。
/* Button.module.css - CSS Modules 示例 */
.button {padding: 12px 24px;border-radius: 6px;background: var(--color-primary);color: white;
}
对开发者的技能栈影响
工作流与构建工具
随着对 CSS-in-JS 的依赖降低，构建工具链的角色与优化重点会发生转移。打包阶段需要更强的静态分析、变量解析和按需加载能力，以实现与传统 CSS 的无缝协作。开发者将关注的技能点包括对 CSS 变量、PostCSS 插件、以及原生 CSS 特性的掌握，以确保样式在不同环境中的一致性。
在工作流层面，Vite、Webpack、以及 CI/CD 集成的差异也会被放大评估。构建时间的改善往往与样式的静态化程度直接相关，因此团队需要理解各自工具对静态样式的优化策略。
# 通过 CLI 查看构建输出中的样式结构
$ npm run build --silent | grep -i "css"
测试与可维护性
测试层面，样式回归测试的需求并不会消失；它们可能从运行时样式注入的回归转向对静态输出的断言。组件的可预测性和可重复性成为可维护性的重要指标，快照测试、视觉回归与 token 化的覆盖面都需得到重视。
与此同时，样式命名与作用域的约束会变得更加重要。使用明确的命名模式、边界约定和设计令牌的命名规范，有助于跨团队协作，降低样式冲突的风险。
// 快照测试示例（伪代码）
expect(render()).toMatchSnapshot();
跨团队协作与代码可读性
撤出 CSS-in-JS 的决策会让前端团队在跨应用协作时，更多地依赖于统一的样式指南和设计系统文档。可读性和一致性成为关键衡量指标，而非仅凭组件内联样式的直观灵活性来判断好坏。
在这种迁移中，清晰的设计令牌定义、统一的命名体系与可追溯的源头样式，可以显著提升团队的协作效率，同时降低样式相关的错误率。
替代方案与最佳实践分析
CSS Modules与传统CSS的对比
在不使用 CSS-in-JS 的前提下，CSS Modules 提供了局部作用域的样式隔离，兼具可读性与可维护性。局部作用域避免了全局命名冲突，且与现有的构建工具链兼容性良好。对于経験丰富的开发者而言，从全局样式表到模块化 CSS 的转变是一个渐进过程，且风险较低。
下面展示一个简单的 CSS Modules 实例：
/* Button.module.css */
.button {padding: 12px 24px;border-radius: 6px;background: var(--color-primary);color: white;
}
// Button.jsx
import styles from './Button.module.css';
export function Button() {return <button className={styles.button}>提交</button>;
}
通过这样的结构，可维护性与可预测性显著提升，但也意味着团队需要管理更多的文件与依赖关系，且设计令牌的全局性需要以 CSS 变量或其他形式稳妥实现。
原子 CSS 与设计令牌的组合
原子化的 CSS 风格（atomic CSS）强调最小单元的可复用性，与设计令牌结合，可以实现高效的样式复用与快速裁剪。原子 CSS 的粒度化有助于减少样式重复，提升缓存命中率，同时保持样式可预测性。
示例片段展示了如何通过原子类组合实现按钮风格：
/* 原子类示例可通过工具生成大量短类名 */
.btn { padding: 12px 24px; }
.btn-primary { background-color: var(--color-primary); color: white; }
结合设计令牌，主题切换与全局一致性可以通过简单的类组合实现，而无需在运行时进行样式注入。
PostCSS 与现代 CSS 特性
PostCSS 提供了广泛的插件生态，允许在构建阶段完成变量解析、前缀处理、嵌套语法等技能。利用原生 CSS 的拟态能力，可以实现高效的样式管线，并兼容旧浏览器。
一个常见实践是通过 PostCSS 将 CSS 变量、@custom-properties、嵌套语法等转换为浏览器友好的输出，同时结合模块化策略确保样式的可维护性。
:root { --btn-padding: 12px 24px; }
.button { padding: var(--btn-padding); }
行业趋势与长期影响
前端性能的新基线
在没有运行时样式注入的场景中，静态样式产出与缓存效率成为性能基线，这对首屏时间和总下载量都有积极影响。设计系统也更易于被多端复用，跨平台一致性成为可衡量的目标。
同时，构建工具和运行时框架需要更好地支持静态样式输出的特性，例如增量构建、CSS 提前解析和按需加载等。
// 构建阶段的作用：提取静态 CSS，减轻运行时负担
// 在构建阶段将 design tokens 转换为 CSS 变量
设计系统的可扩展性
随着组织规模的增长，设计系统的可扩展性成为核心竞争力，设计令牌、组件库契约和样式治理需要高度统一。去掉 CSS-in-JS 的实现并不等于放松约束，反而强调通过明确的治理机制来保障一致性。
某些团队在设计系统中采用了多种风格模板的混合：静态 CSS、CSS Modules 与少量的工具链定制，以实现不同场景的最佳权衡。
/* 统一设计令牌对外暴露 */
:root {--radius-small: 4px;--radius-medium: 8px;--color-primary: #2563eb;
}
生态系统的演化
生态系统中对 CSS 的治理正在从“在组件内部注入样式”向“通过设计系统与全局样式管理”的方向演化。工具链的协调性、社区规范与教育成本成为关注点，开发者需要在不同工具之间保持熟练度，以应对跨项目协作的复杂性。
总体来看，Emotion 团队放弃 CSS-in-JS 的举措，促使前端生态在性能、可维护性与规模化设计系统之间寻找新的平衡点。 未来的样式架构将更强调静态化产出、设计令牌治理与跨团队协作的清晰性。
