CSS-in-JS vs 传统CSS：现代样式方案选择指南

从“CSS 冲突”到样式方案的选择：一次痛苦升级后的思考

作为一个经历过多个中大型前端项目的开发者，我深刻体会到在前端开发中最容易被忽视但又最容易带来麻烦的部分——样式管理。尤其是当团队人数增多、项目模块分散、多人并行开发时，传统的 CSS 方案往往会暴露出一些令人头疼的问题。

今天我想和你聊聊我在实际工作中碰到的一个真实案例，以及我们是如何一步步从传统 CSS 过渡到 CSS-in-JS 方案的。这篇文章不讲空洞的理论，全是我在项目实战中的踩坑经历和心得。

---

一、项目背景与问题初现

事情发生在大约两年前，当时我们团队正在重构一个老系统的核心部分。这是一个面向企业用户的后台管理系统，界面功能复杂、组件繁多，前后端分离，采用 React 作为主框架。

一开始，项目沿用了经典的 CSS 模块化方案（CSS Modules）进行样式管理。我们也尝试了 BEM 命名规范，想通过命名约定来降低类名冲突的风险。但随着项目推进，逐渐出现了几个难以忽视的问题：

• 类名重复导致样式混乱：多个组件使用相同或类似命名，如 .container、.title，不同页面之间相互干扰。
• 样式污染严重：全局样式误引入，导致某个基础组件在不同页面呈现不同的表现。
• 协作成本高：新人进来后很难快速理解如何正确使用已有样式，也不容易区分哪些样式是通用的，哪些是特定组件专有的。
• 可维护性差：改一个样式动辄牵一发而动全身，必须小心翼翼地排查影响范围。

这些问题一开始还只是“有点烦”，但到了中后期，已经严重影响了开发效率和产品质量，甚至有几次线上样式崩溃的情况。

---

二、寻找解决方案：我们开始调研新的样式方案

面对这种局面，我们决定重新审视我们的样式管理策略，并开始调研当前主流的几种方案，包括：

1. CSS Modules（我们已用）
2. SCSS + BEM
3. styled-components（CSS-in-JS 的代表）
4. emotion.js
5. Tailwind CSS
6. CSS-in-TS（如 vanilla-extract）

我们的目标很简单：提高样式的封装性和可维护性，减少协作中的样式冲突问题。

最终，我们选择从 styled-components 入手做试点，原因如下：

• 支持组件级别的样式隔离（自带 scoped 样式）
• 可以使用 JavaScript 表达动态样式逻辑
• 支持主题配置、样式复用等高级功能
• 社区活跃，文档完善，React 集成自然

---

三、实践过程：第一次尝试 CSS-in-JS

我们在某一个业务模块中开始了尝试，选的是权限管理页面下的一个“权限卡片组件”。这个组件需要根据不同角色状态显示不同颜色边框和图标，样式变化较频繁。

1. 初始代码结构（CSS Modules）

// PermissionCard.jsx
import styles from './PermissionCard.module.css';

function PermissionCard({ role }) {
  return (
    <div className={styles.card}>
      <div className={`${styles.header} ${role === 'admin' ? styles.admin : ''}`}>
        {role}
      </div>
      <div className={styles.content}>...</div>
    </div>
  );
}

/* PermissionCard.module.css */
.card {
  border: 1px solid #ccc;
  padding: 16px;
}

.header {
  font-weight: bold;
}

.admin {
  color: red;
}

这种方式写起来没有问题，但问题是：

• admin 类可能在其它组件里也定义过
• 如果以后要动态控制颜色怎么办？比如根据用户设置或者角色动态切换

于是我们尝试换成 styled-components：

2. 使用 styled-components 改造

// PermissionCard.styled.js
import styled from 'styled-components';

export const Card = styled.div`
  border: 1px solid #ccc;
  padding: 16px;
`;

export const Header = styled.div`
  font-weight: bold;
  color: ${({ theme, role }) => (role === 'admin' ? theme.colors.red : theme.colors.default)};
`;

// PermissionCard.jsx
import { Card, Header } from './PermissionCard.styled';

function PermissionCard({ role }) {
  return (
    <Card>
      <Header role={role}>{role}</Header>
      <div>...</div>
    </Card>
  );
}

改造之后最明显的变化是：

• 类名完全隔离，不再担心冲突
• 样式直接和组件绑定，阅读代码时不需要来回跳转查看 CSS 文件
• 动态样式更加直观，可以通过 props 或者 theme 直接控制

这次试点效果很好，团队成员也反馈说“写起来更舒服了”。

---

四、遇到的坑：CSS-in-JS 也不是完美的

虽然初步尝到了甜头，但在后续大规模推广的过程中，我们还是遇到了不少坑。

1. 构建性能下降

初期我们发现构建时间显著增长，尤其是开发服务器启动变慢了很多。

分析原因：

• styled-components 是运行时解析样式，在开发模式下每一个组件都会动态插入 <style> 标签，导致渲染帧率波动
• HMR 热更新速度明显变慢

解决办法：

• 引入 Babel 插件 babel-plugin-styled-components 来优化生成的 class 名称，便于调试和提升 HMR 性能
• 在生产环境启用 @loadable/babel-plugin 实现动态导入优化

2. SSR 支持不够友好

我们要做 SEO，所以服务端渲染（Next.js）非常重要。但在集成过程中发现：

• 页面首次加载时，客户端和服务器渲染出的样式不一致（FOUC），出现短暂样式错乱
• styled-components 默认是按需注入样式的，服务端无法自动收集所有样式代码

解决方案：

• 引入 styled-components 提供的 ServerStyleSheet 组件，手动收集服务端渲染产生的样式，并注入 HTML 头部
• 升级到最新版本，支持更完善的 SSR 支撑

示例代码如下：

// pages/_document.js (Next.js)
import { ServerStyleSheet } from 'styled-components';

export default class MyDocument extends Document {
  static async getInitialProps(ctx) {
    const sheet = new ServerStyleSheet();
    const originalRenderPage = ctx.renderPage;

    try {
      ctx.renderPage = () =>
        originalRenderPage({
          enhanceApp: (App) => (props) =>
            sheet.collectStyles(<App {...props} />),
        });

      const initialProps = await Document.getInitialProps(ctx);
      return {
        ...initialProps,
        styles: (
          <>
            {initialProps.styles}
            {sheet.getStyleElement()}
          </>
        ),
      };
    } finally {
      sheet.seal();
    }
  }
}

3. 样式复用机制不如预期灵活

在传统 CSS 中，我们可以很方便地通过 .btn.primary {} 加多个类名的方式来实现组合式样式。而在 CSS-in-JS 中，虽然可以继承组件，但有时显得不够直观。

比如我们有个通用按钮组件：

const Button = styled.button`
  padding: 8px 16px;
  background-color: #eee;
  border-radius: 4px;
`;

const PrimaryButton = styled(Button)`
  background-color: #007bff;
`;

虽然写法没问题，但如果你有很多变体，维护起来还是比较繁琐，特别是嵌套层级多了之后会感觉很绕。

改进方式：

• 我们结合了 styled-components 和一些 utility 函数，把常用样式抽离成工具函数
• 后期引入了 polished，用于颜色操作、混色等功能

---

五、收益总结：样式终于回归可控

经过几个月的逐步替换，我们将项目中超过 80% 的模块迁移至 styled-components 方案后，整体感受如下：

✅ 积极收益：

• 样式冲突几乎消失：每个组件都有独立的类名前缀，互不影响
• 样式复用变得更灵活：可以通过 props 控制样式行为，也可以通过主题统一控制视觉风格
• 调试更容易：浏览器上可以直接看到哪个组件对应的样式，不再需要反复找 CSS 文件
• 提升团队协作效率：新同事能够快速理解样式逻辑，不需要额外解释“怎么命名才不会冲突”

⚠️ 小遗憾：

• 开发体验稍有拖累（热更新变慢、初次加载卡顿感增强）
• 对 SSR 支持需要额外处理，增加了维护成本
• 学习曲线对新人来说略陡峭

但总体而言，利远大于弊。

---

六、现在我给你的建议

如果你正在考虑是否要在项目中使用 CSS-in-JS，以下是我结合自身经验的一些建议：

✅ 推荐使用的场景：

• React/Vue/前端组件化程度高的项目
• 需要高度封装组件库 / UI Kit
• 团队规模较大、协作频繁
• 需要支持主题定制 / 暗黑模式等动态样式需求

❌ 不推荐使用的场景：

• 小型静态页面项目
• SEO 要求极高、完全依赖 SSR
• 技术栈老旧、无法支持现代 JS 特性
• 性能极其敏感的高并发应用（如高频交易面板）

---

七、其他可替代方案简要说明

除了 styled-components，还有一些不错的替代方案：

工具	优点	缺点
emotion.js	支持 CSS Object、JSX 标签两种写法，编译时插件性能更好	API 略显复杂
vanilla-extract	零运行时，类型安全，适合 TS 用户	上手难度大，学习曲线陡
Tailwind CSS	工具类即用即走，开发效率高	类名臃肿，语义不强，调试不便

这些工具各有所长，可以根据团队实际情况选择。

---

八、个人感悟：样式也是架构的一部分

过去我一直觉得样式是“次要”的，只要看起来差不多就行。但经历了这场从传统 CSS 到 CSS-in-JS 的过渡后，我真正意识到：样式也是一种架构设计，它直接影响着项目的可维护性、扩展性以及团队的协作效率。

在现代前端开发中，组件化已经深入人心，样式管理也应该与时俱进。CSS-in-JS 并不是万能钥匙，但它为我们提供了一种更现代化、更灵活的样式组织方式，值得在合适的项目中深入尝试。

---

最后送大家一句话

“好的样式，不是让人看不见它的存在，而是让人根本意识不到它曾经是个问题。”

愿你在代码中写出漂亮的组件，在样式里写出优雅的逻辑 🎨✨

---

本文作者曾就职于一线互联网公司，负责多个中大型 React 应用的设计与开发，对前端工程化和组件化体系有深入实践与思考。