CSS-in-JS vs 传统CSS：现代样式方案选择指南
CSS-in-JS vs 传统CSS：现代样式方案选择指南
引言：一次重构让我彻底重新思考了样式管理方式
去年我们团队要做一次比较大的项目重构，原项目是一个大型后台管理系统，页面复杂、组件多、样式逻辑交织混乱。原来的样式是用传统CSS + BEM规范写的，整体结构已经有点失控，出现了命名冲突、样式覆盖难追踪等问题，尤其在多人协作时非常痛苦。
我当时负责其中一个核心模块的重构工作，面对这种“旧债缠身”的状况，我决定不走老路，尝试一下最近讨论比较多的CSS-in-JS方案，比如 styled-components 和后来切换到更轻量的 emotion。整个过程不是一帆风顺，但也确实让我对前端样式的组织方式有了新的认知。
今天我就想从这次经历出发，聊一聊我在实际工作中使用过的技术选型，以及它们的优缺点和适用场景——希望对你做出自己的技术决策有所帮助。
背景与问题描述：样式越来越难管，团队协作也越来越痛
这个项目原本用了传统的 CSS 文件配合 SASS 预编译，并严格遵循 BEM 命名规范。但随着业务迭代加速，组件越来越多，很多开发同学为了图方便就开始随意添加 .class，或者套娃写法太多导致难以维护。
举个例子：
<!-- 这是某个卡片组件 -->
<div class="user-card user-card--large user-card__header user-card__footer user-card__action">
你很难一眼看出哪个类真正起作用，也容易出现层级嵌套过度导致样式失效或优先级混乱的问题。
而且因为样式文件分散在各个目录，不同人修改时可能覆盖他人定义的样式规则。尤其是某些通用组件（如按钮、表格）被多个功能引用时，改一处就会牵动其他地方，出错后排查很费劲。
我们急需一种能更好地隔离样式、提升可维护性的方案。
解决思路：为什么我要考虑 CSS-in-JS？
当时我想到了几个方向：
- 继续优化 BEM 命名策略 + CSS Modules —— 比较稳妥
- 采用 CSS-in-JS 方案（如 styled-components、emotion） —— 更现代化
- 纯 CSS 工具类框架（如 Tailwind CSS） —— 效率高但样式抽象不足
最终我选择了第2条路线，因为我觉得：
- CSS-in-JS 更适合组件化开发，样式直接绑定在组件上，便于理解与维护。
- 可以利用 JavaScript 的动态能力，实现条件渲染样式、主题配置等高级功能。
- 样式作用域天然隔离，避免全局污染。
于是我开始调研相关库，并结合我们的项目特性做了一个小试点：把一个核心 UI 组件（用户操作面板）改为使用 emotion 来管理样式。
技术方案实践与关键代码
我们最后选用的是 @emotion/react + @emotion/styled 组合，理由如下：
- 支持 React JSX 中内联样式对象
- 支持 styled API，像写 SCSS 一样写出组件样式
- 构建时自动提取 CSS，不影响 SEO 和加载性能
- 社区活跃且文档清晰
1. 内联样式对象示例（适合简单组件）
import { css } from '@emotion/react';
const Panel = ({ title, children }) => {
return (
<div
css={css`
background: #f5f5f5;
border-radius: 6px;
padding: 16px;
box-shadow: 0 1px 4px rgba(0, 0, 0, 0.08);
max-width: 600px;
margin: auto;
@media (max-width: 768px) {
padding: 12px;
}
`}
>
<h3>{title}</h3>
<div>{children}</div>
</div>
);
};
这种方式非常适合一次性使用的 UI 小组件，可以直接在 jsx 里面写样式，阅读性很好。
2. 使用 styled 定义带样式的组件（适合复用性高的组件）
import styled from '@emotion/styled';
const Button = styled.button`
background: ${(props) => props.primary ? '#1976d2' : '#eee'};
color: ${(props) => props.primary ? '#fff' : '#333'};
border: none;
padding: 12px 16px;
font-size: 14px;
border-radius: 4px;
cursor: pointer;
&:hover {
opacity: 0.9;
}
`;
// 使用
<Button primary>提交</Button>
<Button>取消</Button>
这段代码实现了根据 props 切换颜色的功能，而且完全封装在组件内部，外部无法影响其样式，这比传统的 CSS 更加灵活。
实践中遇到的“坑”和解决方法
虽然整体体验不错，但在过程中也遇到了几个实际问题，分享出来希望能帮你避坑。
🐞 1. SSR 环境下样式闪烁（FOUC）
我们在项目中使用 Next.js 做服务端渲染，一开始发现首屏加载时会短暂出现未应用样式的状态（FOUC），看起来就像页面跳动了一下。
🔍 分析原因：Emotion 默认是在客户端注入样式，而服务端没有提前注入样式内容。
✅ 解决办法：
我们通过 Emotion 提供的 _app.tsx 插入机制来插入样式标签。官方提供了 CacheProvider 和自定义 renderToString 方法支持。
具体步骤可以参考 Emotion 的官方文档 Using with Next.js，核心是创建一个 cache 并在 _document.tsx 中渲染 <style> 标签。
🐞 2. 构建体积问题
我们在生产构建时发现打包后的 vendor chunk 大了一截，分析后发现是 emotion 注入运行时插件所增加的部分。
✅ 解决方法：
我们启用 Emotion 的 @emotion/babel-plugin 进行 CSS 提取，并配置构建流程将运行时样式剥离成单独的 CSS 文件。
// 在 .babelrc 中
{
"plugins": ["@emotion"]
}
这样就可以减少 JS bundle 中的样式处理逻辑，只留下必要的 runtime。
🐞 3. 动态样式的调试困难
有时候我们会通过 props 控制样式的计算，但调试时不太方便看生成的类名和对应的样式。
✅ 解决方法：
Emotion 支持 label 属性，可以帮助开发者在 DevTools 中识别组件样式：
const Box = styled.div(props => ({
width: props.width,
label: 'custom-box-style'
}))
然后在浏览器 Elements 面板里能看到类似这样的类名：
.css-123abc-custom-box-style
这对我们定位问题很有帮助！
成果回顾：样式变好管了，效率也有提升
经过一段时间的应用，效果还是挺明显的：
- 组件样式可读性提高：样式跟组件在一起，新人接手成本降低
- 样式冲突大幅减少：每个组件都有独立的 scope，不会互相干扰
- UI 主题控制更便捷：借助 emotion 的 ThemeProvider 可以轻松做暗色模式等需求
- 团队协作更顺畅：不需要再约定复杂的 class 命名规则
我们也逐渐将老项目的样式逐步迁移进来。当然，并不是所有地方都用了 emotion，比如静态页和 SEO 相关的内容依然保留了传统 CSS。
我的经验总结：什么时候该用 CSS-in-JS？什么情况下建议用传统 CSS？
在我多年的实战经验中，我总结出了以下几个判断依据：
✅ 建议使用 CSS-in-JS 的场景：
- React/Vue 等基于组件体系的项目
- 需要根据 prop 或状态动态改变样式的情况
- 团队规模较大，有频繁协作需求
- 需要良好的样式作用域隔离和主题系统
- 使用 TypeScript 可以获得类型推断（emotion 支持很好）
✅ 建议使用传统 CSS 的场景：
- 页面较为静态，样式变化不多
- 对构建产物大小敏感，追求极致优化
- 团队成员熟悉 BEM / CSS Modules 等工程化规范
- 使用非组件框架（如 jQuery / vanilla js）
- 项目需要良好的兼容性，不想引入额外依赖
我个人认为，对于现代的前端项目，尤其是以 React 为主的 SPA 应用，CSS-in-JS 是值得尝试甚至推荐的，特别是当你遇到样式管理混乱、命名冲突等问题的时候。
给你的几点建议与工具推荐
优先从 CSS Modules 开始试水
如果你不准备一下子全部转向 CSS-in-JS，可以从 CSS Modules 入手，它提供一定的样式作用域隔离，同时学习曲线低。选择合适的库很重要
推荐尝试以下主流 CSS-in-JS 框架：- emotion：生态完善，支持多种写法，构建友好
- styled-components：社区庞大，文档丰富，风格优雅
- vanilla-extract：适用于更偏底层的项目，支持构建时 CSS 生成
注意性能和调试体验
- 使用 Devtools 查看类名来源，确认是否混淆/重复
- 注意 SSR 的样式插入问题
- 生产环境尽量启用构建时 CSS 提取，避免 JS 注入影响首次渲染
合理拆分样式文件
即使用了 CSS-in-JS，也不要一股脑把所有样式写在组件里。可以把复杂组件拆分出 styles.ts 或 styles.js，保持结构清晰。
结语：别迷信，别抗拒，适合自己才是最好的
样式这件事，从来就没有标准答案。CSS-in-JS 不是银弹，也不是灵丹妙药。它只是给我们多了一种解决问题的方式。
我曾经也坚信 BEM 是终极方案，直到项目变得足够复杂，才意识到我们需要更灵活、可组合的样式管理方式。CSS-in-JS 让我重新认识了“样式即组件”的理念，也让前端开发变得更像在写逻辑代码，而不是写魔法注释般的 class 名称。
如果你也在面临类似的困扰，不妨试试看这套方案。不要怕折腾，在真实业务中验证技术的价值，才是我们作为工程师最重要的事情。
毕竟，写代码，不只是写功能，更是写未来可维护的代码。
评论 0