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

张艳

2025-06-30 12:59

阅读 660

CSS-in-JS vs 传统CSS：我为什么在项目中从传统CSS转向styled-components？

作为一名前端开发者，我在过去几年里参与过多个中大型 React 项目的开发。在这个过程中，样式管理始终是一个避不开的话题——尤其是在团队协作、组件复用和可维护性要求越来越高的今天。

今天我想和大家分享的是我亲身经历的一次项目“样式重构”历程。我们原本使用的是传统的 CSS + BEM 命名方法，但随着项目逐渐变大，样式冲突、命名混乱、组件间样式耦合等问题逐渐暴露出来。于是我们开始尝试引入 CSS-in-JS 方案中的 styled-components，并最终取得了不错的效果。

这篇文章就是基于那次实战经验写的，希望能帮你少走一些弯路。

背景与挑战

我们的项目是一个面向企业用户的后台管理系统，技术栈是 React + TypeScript + Redux。整个项目结构采用模块化设计，每个模块都包含自己的组件、业务逻辑和样式文件。

最初，我们使用传统的 CSS 文件来管理样式：

/* Example: Dashboard.css */
.dashboard {
  padding: 20px;
}

.dashboard__title {
  font-size: 18px;
  color: #333;
}

并在组件中通过 import 引入：

import './Dashboard.css';

const Dashboard = () => (
  <div className="dashboard">
    <h1 className="dashboard__title">欢迎回来</h1>
  </div>
);

刚开始一切都很顺利，但随着组件数量增加到 50+，问题开始显现：

样式冲突频繁发生：不同页面之间有同名 class（比如 .card, .modal），导致样式互相覆盖。
难以追踪样式来源：当一个元素样式出错时，需要反复查看多个 CSS 文件才能找到定义。
组件样式无法封装：某些通用组件的样式被全局污染，很难做到真正意义上的“复用”。
主题切换困难：想要统一修改颜色或字体风格时，需要手动改多处 CSS 文件。

这些问题虽然不至于让项目瘫痪，但却严重影响了开发效率和代码质量。

尝试解决方案：为何选择 styled-components？

在项目中期评审会上，我们提出了样式管理方案优化的需求。当时有几个选项：

继续使用传统 CSS，但引入更严格的命名规范和文件组织方式；
使用 CSS Modules，在打包阶段做局部作用域处理；
尝试 CSS-in-JS 方案，例如 styled-components 或 emotion。

我们评估之后，选择了 styled-components，主要有以下几个理由：

它天然支持动态样式和变量注入，非常适合组件化开发；
样式写在组件内部，更容易理解上下文和复用；
支持主题（theme）机制，便于做全局视觉定制；
社区成熟，文档友好，React 开发者社区接受度高。

当然我们也考虑了可能的风险，比如运行时性能、服务端渲染兼容性等。但在实际测试后发现这些问题都可以解决。

实践过程：如何一步步迁移到 styled-components？

迁移并不是一蹴而就的，我们采用“渐进式重构”的策略，逐步将老样式替换为 styled-components 的写法。

第一步：安装并配置 styled-components

我们在项目中安装：

npm install styled-components

并添加了 TypeScript 支持所需的插件：

npm install --save-dev @types/styled-components

然后在项目根目录创建了一个 theme.ts 文件用于主题定义：

// theme.ts
export const defaultTheme = {
  colors: {
    primary: '#4a90e2',
    background: '#f7f8fa',
    text: '#333',
  },
  spacing: (factor: number) => `${factor * 8}px`,
};

再配合 <ThemeProvider> 包裹整个应用：

import { ThemeProvider } from 'styled-components';
import { defaultTheme } from './theme';

const App = () => (
  <ThemeProvider theme={defaultTheme}>
    <Router>
      <Routes />
    </Router>
  </ThemeProvider>
);

第二步：编写第一个 styled-component

我们先从一个常用的小组件开始重构。比如按钮组件：

import styled from 'styled-components';

const StyledButton = styled.button`
  padding: ${props => props.theme.spacing(1)} ${props => props.theme.spacing(2)};
  background-color: ${props => props.theme.colors.primary};
  color: white;
  border: none;
  border-radius: 4px;
  cursor: pointer;

  &:hover {
    opacity: 0.9;
  }
`;

export const Button = ({ children }) => (
  <StyledButton>{children}</StyledButton>
);

这样做的好处很明显：

样式逻辑集中在组件中，容易理解和维护；
通过 theme 可以实现统一的主题控制；
类名自动唯一生成，避免冲突；
写法接近 CSS 原生语法，学习成本低。

第三步：逐步替换老样式

我们将所有核心组件依次进行重构，同时保持其他部分不变。这期间遇到的最大问题是：

如何共存？旧 CSS 和新的 styled-components 是否会产生干扰？

答案是可以的。两种方式可以并行使用。只需要注意不要使用 global styles 相关功能影响已有样式即可。

遇到的坑和解决方法

1. SSR 渲染下的样式丢失问题

在我们引入 styled-components 后，首次部署到服务器时发现，页面首次加载时会出现短暂的“未样式化”状态（FOUC），特别是首屏内容会闪一下才正确显示样式。

这是由于 styled-components 在客户端和服务端生成的类名不一致造成的。

解决方法：

我们采用了 Next.js 作为服务端框架，因此可以通过内置的 ServerStyleSheet 来收集样式，并注入到 HTML 中：

// pages/_document.tsx
import { ServerStyleSheet } from 'styled-components';

export default function Document() {
  return (
    <Html lang="zh-CN">
      <Head>
        {/* 其他 meta */}
      </Head>
      <body>
        <Main />
        <NextScript />
      </body>
    </Html>
  );
}

Document.getInitialProps = async (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: [
        ...React.Children.toArray(initialProps.styles),
        sheet.getStyleElement()
      ]
    };
  } finally {
    sheet.seal();
  }
};

这一步解决了服务端渲染下样式缺失的问题。

2. 动态样式性能问题

有些组件我们需要根据 props 动态改变样式，比如：

const Box = styled.div<{ active?: boolean }>`
  background: ${props => (props.active ? '#eee' : '#fff')};
`;

这种做法在小规模场景没问题，但如果大量使用可能会导致性能下降（因为每次都会重新计算样式）。

解决方法：

对于静态值尽量提取为变量或者使用常量；
对于频繁变化的部分，结合 React.memo 进行组件缓存；
如果样式特别复杂，可以用 as 属性动态改变元素类型而不必每次都新生成 style 标签；

3. 模拟伪类和动画变得麻烦

CSS 中我们习惯用 :hover, @keyframes 等语法，而在 styled-components 中写这些需要一定技巧。

举个例子，模拟悬停动画：

const AnimatedBox = styled.div`
  transition: all 0.3s ease;

  &:hover {
    transform: scale(1.05);
  }
`;

这个没问题，但如果要定义 keyframes 动画呢？

import { keyframes } from 'styled-components';

const rotate = keyframes`
  from { transform: rotate(0deg); }
  to { transform: rotate(360deg); }
`;

const Spinner = styled.div`
  animation: ${rotate} 1s linear infinite;
`;

这种方式是可行的，不过对刚接触的人来说不太直观。好在文档很全，社区示例也很丰富，基本能解决所有需求。

最终效果与收益总结

完成迁移后，整个项目在多个方面都得到了提升：

✅ 开发体验显著改善

组件样式与行为绑定在一起，阅读代码时无需来回跳转 CSS 文件；
使用主题 API 后，统一调整 UI 主题变得更加容易；
所有组件样式默认隔离，再也不怕命名冲突；
动态样式的传参方式非常灵活，适合各种交互场景。

✅ 构建稳定性增强

不再依赖 CSS 文件引用顺序，避免了 CSS 加载顺序导致的样式错乱；
自动类名机制保证了组件之间的互不影响；
Webpack Tree-shaking 也能更好地识别无用样式，减少打包体积。

✅ 用户体验也有所提升

SSR 下 FOUC 问题解决后，页面打开更加稳定流畅；
通过合理使用 keyframes、transition 提升了界面动效的精致度；
利用 media query 和响应式设计语法，使移动端展示效果更好。

我的建议与注意事项

如果你也在纠结是否应该从传统 CSS 转向 CSS-in-JS，或者在两个方案之间做抉择，以下是我根据这次实践经验给出的一些建议：

📌 优先考虑使用场景

如果你的项目是中大型 React 应用，组件化程度高，追求良好的封装性和可维护性，那么 styled-components 或 emotion 是不错的选择；
如果你是在维护一个老项目，已经大量使用了传统 CSS，而且没有明显痛点，那没有必要盲目重构；
如果你使用 Vue 或 Angular，CSS-in-JS 的生态支持不如 React 成熟，建议优先考虑 scoped-style 等官方方案。

📌 注意性能边界

CSS-in-JS 是运行时插入 <style> 标签的方式工作，所以如果过度滥用，也可能带来一定的性能负担。建议：

控制组件层级深度，避免过度嵌套 styled-components；
复杂样式逻辑尽量抽离成变量而不是直接写在模板字符串中；
使用 React.memo 减少不必要的样式重计算。

📌 工具链要跟上

使用 styled-components 后，调试方式也略有不同。推荐几个实用工具：

VS Code 插件：如 "vscode-styled-components"，支持语法高亮；
Chrome DevTools 扩展：styled-components devtools 可以看到组件对应的样式；
TypeScript 支持：记得引入正确的类型定义包，否则 IDE 会报错。

结语：没有银弹，只有权衡

说实话，我以前也坚定地认为传统 CSS 是最稳妥、最高效的方案。直到在这次真实项目中遇到了一系列痛点，才意识到：任何技术都是服务于具体场景的。

CSS-in-JS 并不是完美的解决方案，它有自己的适用范围和潜在缺点。但它在组件化时代提供了另一种思路，尤其是对于追求开发效率和组件复用性的现代前端团队来说，是一个值得深入研究和尝试的方向。

现在回想起来，那一次重构并没有让我后悔，反而让我更清晰地认识到一点：

“好的技术选型，不是因为它流行，而是因为它确实解决了问题。”

希望这篇分享对你有所帮助。如果你也有类似的实践经历，欢迎留言交流。

标签:求职前端

最热最新

暂无评论

为你推荐

暂无相关推荐