4.4 CSS 方案

4.4 CSS 方案

本节摘要：React 项目的样式方案是一条「从全局 CSS 到模块化再到运行时」的演进线。CSS Modules 提供编译期的局部作用域，styled-components 把样式写进 JS 并支持动态主题，Tailwind 用工具类原子化组合样式。本节对比四类方案的原理与代价，给出「按团队与项目选 CSS 方案」的判断。

先说结论

阅读完本节，你应当能够：

1. 解释 CSS Modules 的作用域原理
2. 用 styled-components 创建带动态样式的组件
3. 理解 CSS-in-JS 的运行时开销问题
4. 说明 Tailwind 工具类的思路与优缺点
5. 按团队与项目为 CSS 方案做出选型

一、问题与直觉：全局 CSS 的三大痛点

React 之前，前端样式的主流是「全局 CSS」——一个或几个大样式文件，类名全局可见。它的痛点随着组件化放大：

命名冲突。两个组件都定义了 .title，后加载的覆盖先加载的。组件一多，起类名成了小心翼翼的工程。

作用域泄漏。一个组件的样式意外影响其他组件——改一个小组件，全站样式漂移。

样式与组件分离。样式在单独文件，组件结构变了，样式文件里的选择器跟着改，两边容易脱节。

这三个痛点随项目规模放大：小项目里一个样式文件勉强能撑，组件上百个之后，命名、隔离、联动的问题会集中爆发。CSS 方案的选择，本质是「你打算用多大力气解决这三个痛点」。

React 的组件化放大了这些痛点——组件应该「自带样式」，就像它自带逻辑。围绕「样式怎么和组件绑定」，社区走出了三条路：CSS Modules（编译期模块化）、CSS-in-JS（运行时动态化）、Tailwind（工具类原子化）。

二、CSS Modules：编译期的局部作用域

CSS Modules 的思路：每个 CSS 文件是一个模块，类名在构建时被转成唯一名，从而实现「局部作用域」。

// Button.module.css
.button {
  background-color: #4CAF50;
}
.primary {
  background-color: #008CBA;
}
​

// 组件里导入
import styles from './Button.module.css';
function Button({ primary, children }) {
  const classes = [styles.button];
  if (primary) classes.push(styles.primary);
  return <button className={classes.join(' ')}>{children}</button>;
}
​

.button 在构建时会被转成类似 Button_button__abc123 的名字。两个组件里都写 .button，编译后互不冲突——冲突在编译期就消失了。

CSS Modules 的收益：

• 局部作用域：类名只在模块内有效，无冲突
• 与组件同文件：样式和组件绑定，维护方便
• 零运行时：构建期完成，无运行时开销
• 兼容好：CSS 语法照写，学习成本低

它的代价：类名访问要通过 styles 对象，动态拼接类名略繁琐；处理全局样式（reset、字体）要单独配置 global 文件。

CSS Modules 的组合与复用

CSS Modules 支持 composes，把多个类名的规则组合起来：

.base {
  padding: 8px 16px;
}
.primary {
  composes: base; /* 复用 base 的规则 */
  background-color: #008CBA;
}
​

composes 让「基础样式 + 变体样式」的组合用 CSS 语法表达，比 JS 里拼类名数组更贴近 CSS 直觉。它也可以跨文件 composes，把「设计 token」集中在一个模块里复用。这是 CSS Modules 被低估的能力——它的表达力比「一个类名一套规则」丰富得多。

与 CSS 变量的配合

CSS Modules 和 CSS 变量（自定义属性）是天然搭档——变量解决「跨模块共享值」，Modules 解决「类名作用域」。两个正交问题，两个正交方案，配合起来没有冲突：

/* theme.css 定义变量 */
:root {
  --brand-color: #008CBA;
}
/* Button.module.css 使用变量 */
.button {
  background-color: var(--brand-color);
}
​

主题切换时改 :root 里的变量值，所有用 var 的地方跟着变，组件的局部类名完全不用动。这个组合比「样式里硬编码颜色」好维护得多，也是很多团队「CSS Modules + CSS 变量」双方案并行的原因。

三、styled-components：CSS-in-JS 的运行时方案

CSS-in-JS 的思路是把 CSS 写进 JavaScript，组件与样式融为一体。styled-components 是代表——用模板字符串定义样式，生成带唯一类名的组件。

import styled from 'styled-components';
const Button = styled.button`
  background-color: #4CAF50;
  color: white;
  padding: 15px 32px;
  &:hover {
    opacity: 0.8;
  }
  ${props => props.primary && `
    background-color: #008CBA;
  `}
`;
function App() {
  return (
    <div>
      <Button>默认按钮</Button>
      <Button primary>主按钮</Button>
    </div>
  );
}
​

styled-components 的核心能力：

动态样式。${props => ...} 让样式能根据 props 变化——这是 CSS Modules 需要手动拼类名才能做到的事。

主题化。ThemeProvider 提供主题对象，组件样式读取主题变量：

import { ThemeProvider } from 'styled-components';
const theme = {
  primary: '#008CBA',
  spacing: '8px',
};
<ThemeProvider theme={theme}>
  <App />
</ThemeProvider>
​

组件里通过 props.theme 读取主题变量，切换主题时 ThemeProvider 传新对象即可——主题从「CSS 变量手动换」变成「一个 Provider 全局换」。这种「主题即上下文」的模型，和 Context 的 Provider 思路一脉相承，也是 CSS-in-JS 相对传统 CSS 的一个结构性优势。

自动唯一类名。运行时生成带哈希的类名，无冲突。

CSS-in-JS 的代价：

• 运行时开销：样式在 JS 里定义，运行时生成 CSS 并注入 DOM。样式多时，这部分开销累积。
• 包体积：样式定义在 JS 里，加大 JS 包。
• 调试难度：类名是运行时生成的哈希，DevTools 里定位要靠 styled-components 提供的组件名提示。

一张表看出本质：CSS Modules 把「动态」的代价放在 JS 里（手动拼类名），styled-components 把「动态」的代价放在运行时（运行时生成样式）。哪个更值得，取决于你的项目「动态样式多不多」——动态多选 CSS-in-JS，动态少选 CSS Modules，成本更低。

styled-components 的组件复用

styled-components 最有价值的一点是「样式组件化」——样式不再是散落的类名，而是可组合的组件。通过继承与组合，样式的复用变成组件的复用：

import styled from 'styled-components';
const Button = styled.button`
  padding: 10px 20px;
  border-radius: 4px;
`;
const PrimaryButton = styled(Button)`  // 继承 Button 的样式
  background: #008CBA;
  color: white;
`;
const LargeButton = styled(Button)`
  padding: 16px 32px;
`;
​

PrimaryButton 和 LargeButton 复用 Button 的基础样式，各自叠加差异。这种「样式继承」的表达力和组件模型完全一致——样式是组件系统的第一等公民。对比 CSS Modules 的 composes，styled-components 的继承更贴近 React 心智，代价是运行时成本。

四、Tailwind：工具类的原子化思路

Tailwind 走的是完全不同的路——不写「语义化类名」，而是用原子化的工具类组合样式：

function Button({ children }) {
  return (
    <button className="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
      {children}
    </button>
  );
}
​

bg-blue-500 是背景色，py-2 px-4 是内边距，rounded 是圆角——每个类名对应一条 CSS 规则，组合起来描述完整样式。

Tailwind 的优势：

• 样式与结构同处：类名就在 JSX 里，改样式不用切文件
• 约束设计：颜色、间距、字号走预定义的体系，设计一致性天然
• 按需生成：构建时只生成用到的工具类，最终 CSS 体积小
• 响应式内联：md:flex、lg:hidden 直接在类名里写断点

响应式是 Tailwind 的一个亮点：不用写媒体查询块，类名里的前缀直接表达断点。一个类名 md:flex 表示「在中等宽度以上用 flex」，响应式逻辑和布局代码写在一起，读起来是「这个元素在什么尺寸下是什么布局」，比看一段独立的媒体查询直觉得多。

Tailwind 的代价：

• 类名冗长：一个元素几十个类名，视觉噪音大
• 学习成本：要记 Tailwind 的类名体系
• HTML 语义丢失：类名描述样式而非含义，语义要靠组件名补

Tailwind 的配置与扩展

Tailwind 的价值很大程度在「可配置」——默认的主题（颜色、间距、断点）只是起点，几乎每个项目都要定制。tailwind.config 里可以改主色、加断点、扩展工具类：

// tailwind.config.js（示意）
module.exports = {
  theme: {
    extend: {
      colors: {
        brand: '#008CBA',
      },
      spacing: {
        '18': '4.5rem',
      },
    },
  },
};
​

配了 brand 色后，bg-brand、text-brand 这些工具类直接可用，全站主色统一从配置里出。Tailwind 的「约束设计」精髓就在这——样式不靠每个人自由发挥，而是从配置体系里选。设计的一致性由配置保证，而不是靠自觉。

💡 关键直觉：CSS Modules 解决「冲突」，styled-components 解决「动态」，Tailwind 解决「效率」。三个方案回答的问题不同——先搞清楚你最痛的是哪个问题，再选方案。

五、方案选型

这张表不是「评分排行」，而是「场景映射」。每种方案都有明确的主场，也有明显的短板——CSS Modules 缺动态、styled-components 有运行时成本、Tailwind 类名冗长。选型就是把「你最受不了的问题」和「方案最强的能力」对上。

⚠️ 常见坑：追潮流换方案。CSS 方案迁移成本极高——全部组件的样式写法都要改。除非现有方案已经严重阻碍开发，否则「能跑就别折腾」。样式方案的选择是「团队技能 + 项目约束」的结果，不是「哪个最流行」。

CSS-in-JS 的性能注意

如果选了 styled-components 这类运行时方案，要注意性能纪律：避免在渲染热路径里动态生成样式对象；优先用「类名切换 + 少量动态插值」，别把所有样式都写成 props 插值。运行时生成 CSS 的成本是「每渲染一次可能重新计算」，样式密集的组件要留意。这也是为什么部分团队转向「编译期 CSS-in-JS」方案（如 vanilla-extract）——它在构建期完成，保留动态能力，去掉运行时开销。选型时「能不能接受运行时成本」是决定用哪一类 CSS-in-JS 的关键分界。

六、工程实践：一套务实的组合

现实项目的样式方案往往不是「单选」。一套常见的务实组合：

• 全局样式（reset、字体、CSS 变量）→ 普通 CSS
• 组件局部样式 → CSS Modules 或 Tailwind
• 少量动态样式（主题色、条件样式）→ CSS 变量或条件类名

CSS 变量（自定义属性）是个被低估的底座——它可以在 CSS 和 JS 之间传值，配合主题切换很顺手：

function App() {
  const [theme, setTheme] = useState('light');
  return (
    <div style={{ '--primary': theme === 'light' ? '#333' : '#eee' }}>
      {/* 组件样式里用 var(--primary) */}
    </div>
  );
}
​

CSS 变量还有一层被低估的好处：它绕过了「CSS 和 JS 两个世界」的翻译成本。JS 里改一个值，CSS 里所有 var 引用同时生效——不用遍历 DOM 改样式，也不用等 React 重渲染。动画、过渡、主题切换走 CSS 变量，比走 React state 更顺滑。

组合的意义：每个方案用在自己最擅长的地方，不迷信单一方案。工具是拼图，不是圣杯——这句话在 CSS 领域尤其成立。

实际项目里怎么定

给团队定 CSS 方案，最实用的方法不是「读文章选型」，而是「试一个最小例子再决定」。拿一个真实的页面（比如登录页或列表页），分别用 CSS Modules、styled-components、Tailwind 写一遍，让团队感受三种写法的体感差异——哪个最顺手、哪个代码量最少、哪个调试最不费力。工具的「手感」是文章讲不清的，亲手试才知道。

另一个提醒：样式方案要和 UI 组件库的选型联动。选 antd，它的样式体系自带；选 shadcn/ui，它绑定了 Tailwind。先定组件库，再定 CSS 方案，顺序反了会给自己找麻烦。

常见疑问快答

「CSS Modules 和普通 CSS + 命名约定，差别在哪？」 差别在「冲突靠机制保证还是靠自觉」。命名约定（BEM 之类）靠团队纪律——每个人都要按规则起名，稍有疏忽就撞名。CSS Modules 靠构建器强制：类名在编译时加哈希，两个文件里的同名类自动互不冲突，规则由工具保证。所以「团队小、纪律好」用命名约定也能撑；「团队大、人流动、组件多」用 CSS Modules 更稳——它把「命名正确」从「人肉保证」变成「编译保证」。这也解释了为什么组件化项目普遍选 CSS Modules：组件拆得越碎，撞名概率越高，越需要机制兜底。

「Tailwind 和组件库能一起用吗？」 能，而且这是当前的主流组合之一。Tailwind 管「自定义部分的样式」，组件库管「现成组件的样式」，两者在「业务自定义页面」上共存——页面布局、间距、响应式用 Tailwind 类名，复杂交互组件（表格、弹窗、日期选择）用组件库。冲突点在「全局 reset 和主题变量」：两个体系都有各自的全局样式，要理清先后与覆盖关系，别让 Tailwind 的 reset 把组件库的样式冲掉。shadcn/ui 就是「Tailwind + 无头组件」的组合，它证明了这套组合的成熟度。关键是分工清晰：Tailwind 管原子样式，组件库管复合组件。

「CSS-in-JS 的运行时开销有多大？值得担心吗？」 值得知道量级，不值得恐慌。运行时 CSS-in-JS（styled-components、emotion）在每次渲染时要把「样式模板字符串」解析成 CSS 规则并注入 DOM——这个开销在样式多、渲染频繁时会累积。对大多数「百级组件」的中型应用，体感不明显；对「组件几千、高频重渲染」的大型应用，可能成为性能瓶颈之一。这也是「编译期 CSS-in-JS」（vanilla-extract、Linaria）存在的理由——它们把样式在构建期编译成静态 CSS，保留「样式和组件同文件」的体验，去掉运行时成本。如果项目里 CSS-in-JS 的性能开始被质疑，往编译期方案迁移是个方向。

「想统一团队的 CSS 方案，第一步做什么？」 别急着「废掉旧方案换新方案」。第一步是盘点现状：项目里现有几种样式写法、各自占比多少、痛点在哪（冲突？动态样式难写？开发效率低？）。第二步是「先定组合框架再选主方案」：全局样式、组件局部、动态样式三层，每层先明确归谁管。第三步是小范围试点——选一个模块用新方案写，团队试用后再推广。直接全量换方案是高风险操作，样式迁移的成本（全部组件重写）往往远超预期。记住 4.4 节的判断：能跑就别折腾，换方案要真有痛点支撑。

样式方案的演进脉络

把四种方案放进一条演进线，能看清它们各自补了什么：

这条线的启发是：每个新方案不是「淘汰」前一个，而是「换个角度解决问题」——Modules 解决冲突，CSS-in-JS 解决动态，Tailwind 解决效率。所以选型不是「追最新」，而是「你最痛的那个问题，哪个方案正好解决」。当前项目最痛的是哪个，就从解决那个问题的方案入手，其余按需组合。这也呼应了本节开头那句话：CSS 方案的选择，本质是「你打算用多大力气解决哪几个痛点」。

要点串联

• 三大痛点：命名冲突、作用域泄漏、样式与组件分离
• CSS Modules：编译期哈希实现局部作用域，零运行时
• composes：CSS 语法组合类名，跨文件复用设计 token
• CSS 变量配合：Modules 管作用域、变量管共享值，主题切换顺手
• styled-components：运行时 CSS-in-JS，动态样式与主题化
• 样式组件化：styled(Button) 继承样式，复用变成组件复用
• CSS-in-JS 代价：运行时开销、包体积、调试难度
• Tailwind：工具类原子化，效率与约束优先
• 方案选型：解决冲突选 Modules，解决动态选 CSS-in-JS，解决效率选 Tailwind
• 组合务实：全局普通 CSS + 组件 CSS Modules/Tailwind + 动态 CSS 变量
• 先组件库后 CSS：CSS 方案要和 UI 库选型联动
• 别追潮流：样式迁移成本高，能跑就别折腾

下一节看其他常用工具——脚手架、状态、UI、样式都定了，剩下的是点状的工具库。axios 请求、Lodash 数据处理、classnames 类名管理、day.js 日期处理、React Hook Form 表单，每个解决一个小而具体的问题，按需取用即可。