React 样式方案众多，每种方案在可维护性、性能、工程化成本上各有优劣。选型不当会导致项目后期样式失控、包体积膨胀或开发效率降低。本节基于真实项目经验，对主流方案进行横向对比。
对比总览
| 方案 | 可维护性 | 性能 | 工程化成本 | 典型适用场景 |
|------|----------|------|------------|--------------|
| 原生 CSS / SCSS | 中等（全局污染风险） | 极佳（零运行时） | 低 | 简单页面、传统多页应用 |
| CSS Modules | 优秀（局部作用域） | 极佳（编译时处理） | 低 | 中大型 React 项目，追求标准 CSS 体验 |
| styled-components | 优秀（组件内聚） | 中等（运行时开销） | 中 | 频繁动态样式的组件库、强主题定制 |
| Emotion | 优秀（功能类似） | 中等（运行时，可配置零运行时） | 中 | 同 styled-components，性能要求略高的项目 |
| Tailwind CSS | 优秀（约束性强） | 极佳（原子化，JIT 编译） | 中（初期学习曲线） | 快速原型、团队规范严、重复样式少的项目 |
可维护性对比
原生 CSS / SCSS
全局作用域容易造成样式冲突，尤其在多人协作时，需要依赖 BEM 等命名规范手动约束。SCSS 的嵌套、变量、mixin 能提升编写效率，但无法从根本上解决作用域问题。长期维护时，样式与组件分离往往导致“不知道哪里用了这个 class”，删除时畏手畏脚。
CSS Modules
通过构建工具（Vite/Webpack）为 class 名自动添加哈希，天然提供局部作用域。样式依然是标准 CSS，开发体验几乎不变，但不再需要担心命名冲突。配合 composes 关键字可实现样式复用，可维护性大幅提升。缺点是全局样式需单独定义（如 :global），动态样式能力较弱。
CSS-in-JS（styled-components / Emotion）
样式定义在组件内部，真正实现“组件级高内聚”。Props 可动态生成样式，主题化、条件样式极其方便。代码可读性高：“看一眼组件就能知道它长什么样”。但随着组件数量增长，大量样式对象或模板字面量可能让组件文件变长，需要结合拆分策略（如将样式提取到同目录文件）保持整洁。
Tailwind CSS
原子化类名强制使用预置的设计 Token，杜绝了随意写魔数的坏习惯，团队协作时样式高度一致。HTML 较长是表面问题，但熟悉后查找和修改都很快，因为样式就在元素上，不需要在文件间跳转。可维护性不仅没有降低，反而因为规范化而提升。如果想抽同复用的样式，可封装成组件或使用 @apply 指令。
性能对比
编译时方案（原生、CSS Modules、Tailwind）
这些方案在构建阶段就生成了纯粹、普通的 CSS 文件，浏览器加载后直接应用样式，没有任何运行时 JS 开销。首屏渲染和样式更新速度最快，尤其对移动端或性能敏感应用有利。Tailwind 配合 JIT 模式只生成使用到的类，最终 CSS 体积极可控。
运行时 CSS-in-JS（styled-components ≤ v5、Emotion 默认）
样式通过 JavaScript 在运行时注入 <style> 标签，存在额外开销：
- 首次渲染：需要解析 JS，将样式序列化为 CSS 再插入 DOM。
- 频繁更新：动态样式改变时需要重新计算和注入，大量组件同时更新可能产生卡顿。
性能差距在数百个组件的页面上开始显现。Emotion 从 v11 起支持 @emotion/css 的零运行时模式，但功能受限。styled-components v6 移向零运行时构建，但目前仍以运行时为主。
影响判断
对于大多数后台管理系统或普通内容页面，性能差异可忽略不计。但在以下场景需谨慎选择运行时方案：
- 高频交互的仪表盘、动画密集型应用
- 移动端 H5 低端机
- SSR 场景（运行时注入会在服务端输出临界 CSS，但仍有性能损耗）
选择零运行时的方案通常更安全高效。
工程化成本对比
原生 CSS / SCSS
无需额外配置，所有框架原生支持，学习成本几乎为零。缺点是后期维护成本高，需要人力约束代码规范。
CSS Modules
Vite 开箱支持，CRA 内置，几乎零配置。引入方式为标准 import styles from './xxx.module.css'，无任何额外依赖。与 PostCSS、Autoprefixer 等工具无缝集成。对构建流程要求极低，适合大多数团队。
CSS-in-JS
需要安装额外库（styled-components、@emotion/react），熟悉其 API 和最佳实践。同时需要配置 Babel 插件（如 babel-plugin-styled-components）来实现更好的调试体验（显示组件名）。强依赖于 JS 运行时，意味着如果组件未渲染，对应样式也不会出现在最终 CSS 中，对代码分割天然友好，但可能导致首次加载时样式闪动（FOUC），需要手动处理关键 CSS。对 SSR 也有额外配置要求。
Tailwind CSS
引入 Tailwind 需要安装 PostCSS 插件和 Tailwind 配置，初期搭建有一定步骤。更关键的是学习成本——团队需要记住大量原子类名（可借助编辑器插件缓解）。一旦团队度过适应期，开发速度极快，且无需在样式文件和组件文件之间频繁切换。VSCode 的 Tailwind CSS IntelliSense 能自动补全和提示，是必备工具。
真实场景选型建议
1. 快速原型 / 个人项目
推荐 Tailwind CSS。极快的开发速度，固定的设计约束能防止样式跑偏。
2. 中小型团队，追求稳定与低心智负担
优先 CSS Modules。标准 CSS 语法无学习成本，局部作用域解决冲突问题，构建产物即为普通 CSS，性能最好。适合成员水平参差不齐、不想引入过多魔法工具的团队。
3. 强组件化、频繁动态样式的组件库或设计系统
选用 CSS-in-JS（Emotion 优先考虑零运行时配置）。基于 Props 的条件样式、主题化能力远超其他方案。同时可利用 facepaint 等库做响应式支持。若对性能敏感，可考虑 vanilla-extract ——基于零运行时 CSS-in-JS 的新秀，TypeScript 原生支持，兼具局部作用域和编译时生成 CSS 的优点。
4. 大型企业应用，重视规范与一致性
Tailwind CSS 或 CSS Modules，配合 Design Token 和代码评审。两种方案都不会有运行时负担，前者强制约束，后者灵活但需额外管控全局变量。
5. 已有大量遗留全局 CSS 的项目
引入 CSS Modules 逐步迁移，新的组件用模块化样式，旧的继续享受全局样式，两种方式可共存。切换成本最低。
避免决策陷阱
- 不要单纯为了“组件内聚”而选用 CSS-in-JS，它适合动态样式多的场景，若组件样式静态，CSS Modules 同样实现内聚且性能更佳。
- 不要“跟风”Tailwind 而忽略团队熟悉度，学习曲线真实存在，如果团队排斥，强制推行会适得其反。
- 不要同时混用太多方案，比如既有 styled-components 又有 CSS Modules 散落各处，这会增加认知负担。一般项目选定 1-2 种即可。
小结
| 场景 | 推荐方案 |
|------|----------|
| 追求极致性能、简单 | CSS Modules |
| 快速开发、原型迭代 | Tailwind CSS |
| 组件库、强动态样式 | Emotion（零运行时）或 vanilla-extract |
| 渐进式改进旧项目 | CSS Modules 与全局 CSS 共存 |
适合团队的方案才是最好的方案。在技术选型时，先根据可维护性、性能要求、团队现状作出选择，并建立一致的样式规范文档，比纠结于工具本身更重要。