从“样式混乱”到模块化：我在前端实战中对 CSS-in-JS 的思考与选择
开篇：为什么这个话题值得聊聊？
刚进公司那会儿，我接手了一个老项目。说实话，那时候我对样式管理的理解还停留在“写个 class，然后在 CSS 文件里定义样式”的阶段。但接手没两天我就发现——这套传统做法，在项目规模变大之后，真的非常容易失控。
我们当时的项目是一个中大型的 React 应用，界面多、组件层级深，不同页面之间又有大量相似但不完全一样的 UI 模块。很快我就意识到一个问题：样式冲突太严重了。
类名重复、全局污染、维护困难……这些传统 CSS 的毛病在这个项目里全都暴露无遗。后来我们尝试引入 CSS-in-JS 方案（比如 styled-components），这才逐渐把局面控制下来。
这篇文章就想结合我这几年的工作经验，和大家聊聊 “CSS-in-JS vs 传统 CSS” 这个经典问题。不是纯理论对比，而是真实场景下的使用感受、踩坑经历和权衡过程。
问题描述：样式管理失控的真实痛感
先说一个让我印象特别深刻的例子。
那是一个表格组件重构的任务。我们原来的 table 是一个封装好的组件，接受各种 props 来控制列宽、主题色、是否可拖拽等状态。看起来很灵活，但背后藏着不少隐患。
举个例子：
const Table = ({ columns, data, theme = 'default' }) => (
<table className={`table-${theme}`}>
{/* ... */}
</table>
)
对应的 CSS 文件长这样：
.table-default {
background-color: white;
}
.table-dark {
background-color: #222;
}
一切看起来都还挺正常的，直到我们在其他业务线复用了这个组件。结果你猜怎么着？他们在自己的样式文件中也定义了个 .table-dark，背景颜色是浅灰色。于是同一个 class 出现了两个样式规则！
这导致的结果就是，同一套组件在不同页面上显示出来的样子不一样 —— 完全取决于谁的样式加载得晚！
这就是典型的 CSS 全局污染，也是我们在传统 CSS 管理方式下最常见的问题之一。
再讲一个协作上的问题。
我们团队当时有 5-6 个人同时开发不同的功能模块，每个模块都有自己的一套样式。但因为大家都用 style.css 或 index.css 这样的通用命名方式，经常出现样式覆盖、互相干扰的问题。
最可怕的是，很多时候样式出错都不是直接报错，而是视觉上“看起来不太对劲”，这就意味着要花很多时间去调试、排查，严重影响开发效率。
这时候我们就意识到：传统的 CSS 管理方式已经撑不住当前的项目复杂度了。我们需要一个新的方案来解决这些问题。
解决方案：探索 CSS-in-JS 的可能性
为了解决样式冲突和管理混乱的问题，我们开始调研 CSS-in-JS 的方案。目标很明确：提高样式隔离性、增强可维护性和提升协作效率。
我们最终选择了 styled-components 作为切入点，并尝试将部分核心组件改造成这种方式。
1. 初步改造尝试：写起来还挺顺手
还是以那个 table 组件为例，我们将其改造成如下形式：
import styled from 'styled-components';
const TableContainer = styled.table`
width: 100%;
border-collapse: collapse;
`;
const darkStyles = `
background-color: #222;
color: #fff;
`;
const defaultStyles = `
background-color: white;
color: #333;
`;
const ThemedTable = styled(TableContainer)`
${({ theme }) => (theme === 'dark' ? darkStyles : defaultStyles)}
`;
const Table = ({ columns, data, theme = 'default' }) => (
<ThemedTable theme={theme}>
{/* ... */}
</ThemedTable>
);
看起来只是写法变了，但实际上变化很大：
- 类名不再是手动定义，而是由库自动生成一串唯一的 hash 值，确保不会冲突。
- 样式逻辑集中在组件内部，而不是分散在多个 CSS 文件中。
- 动态传入的 theme 属性可以直接影响样式，代码更清晰可控。
2. 工程化支持：自动化的快乐来了
除了样式隔离之外，还有一个意外收获是工程化体验的提升。
- styled-components 支持 Server Side Rendering（SSR），样式能正确注入 head 中，避免首屏抖动；
- 支持热更新（HMR），修改样式后组件可以立即刷新，无需重新加载整个页面；
- Chrome DevTools 里能看到每一个组件对应的样式名称，调试起来更加直观。
特别是调试部分，以前查样式冲突的时候需要不断打开 Chrome Elements 面板找 class 名、看优先级、看加载顺序……现在可以直接看到哪个组件写了什么样式，极大地提升了排查效率。
3. 性能优化也不能忽视
当然，CSS-in-JS 不是万能药，也不是完全没有缺点。最常被质疑的就是性能问题，尤其是首次渲染时动态插入 <style> 标签是否会影响性能。
我们做了简单的性能测试，使用 Lighthouse 对比传统 CSS 和 styled-components 在页面加载时的表现：
| 指标 | 传统 CSS | styled-components |
|---|---|---|
| First Contentful Paint | 1.4s | 1.6s |
| Time to Interactive | 2.7s | 3.1s |
| JS 执行时间 | 1.1s | 1.4s |
可以看出，确实存在一定的性能损耗，但在绝大多数现代浏览器下都能接受。如果你的项目规模不大，或者不追求极致性能，这种差距是可以忽略的。
不过对于大型项目来说，我们也可以做一些优化：
- 使用
babel-plugin-styled-components提升 SSR 渲染速度； - 合并共用样式片段，减少重复的
<style>插入； - 对性能要求高的组件，可以回到传统的 CSS Modules 方式。
4. 协作改进：写样式不再吵架了
最大的收益其实是协作上的改善。
以前两个人同时修改样式，很容易出冲突，尤其是在同一个 CSS 文件里，修改的地方挨得太近，Git 合并的时候总是提心吊胆。
而用 styled-components 后，每个人的样式都写在各自的组件文件中，结构清晰，修改范围明确，合并冲突大大减少。即使出现了问题，也能迅速定位是谁写的哪一段样式出了问题。
这也间接提高了代码评审的效率，审代码的人可以看到样式变化的上下文，而不仅仅是一堆 class 名的组合。
效果总结：从混乱走向可控
经过几个月的努力，我们将项目的样式系统逐步迁移到 CSS-in-JS 上，整体效果非常明显：
✅ 优点总结
- 样式隔离做得好：再也不用担心 class 冲突或者样式覆盖；
- 动态样式更容易控制：通过 props 控制样式非常方便；
- 组件即样式单元：样式和结构耦合更紧密，易于理解和维护；
- 调试变得更轻松：DevTools 显示清晰，样式归属一目了然；
- 协作更顺畅：分支合并少了好多冲突，团队幸福感明显上升 🤩。
⚠️ 小小的遗憾
- 首次渲染稍微慢一点（但在现代浏览器下几乎感知不到）；
- 构建体积稍微大了一些（主要是增加了 runtime 成本）；
- 有些复杂的样式写法不太习惯（比如嵌套伪类）。
但总的来说，利远大于弊，尤其当我们项目的组件数量突破 100+ 以后，CSS-in-JS 的优势就愈发明显了。
经验分享：给前端同行们的一些建议
说了这么多实践中的酸甜苦辣，最后我也想总结几点建议，希望对你在技术选型时有所帮助：
1. 不要一刀切，要看项目情况
CSS-in-JS 并不是万能的，它更适合以下几类项目：
- 组件库类项目（组件独立性强，样式隔离要求高）；
- 大型 SPA 项目（结构复杂，多人协作频繁）；
- 需要高度定制主题的项目（可以通过 props + 动态样式快速实现切换）。
反之，如果是：
- 简单的静态页面或内容展示网站；
- 超高性能敏感的场景；
- 项目历史包袱较重，迁移成本过高；
那你可能更适合坚持使用传统 CSS（或者 CSS Modules）来实现样式管理。
2. 推荐搭配 TypeScript 使用
我们在项目中使用的其实是 @emotion/styled（另一款 CSS-in-JS 工具），和 TypeScript 配合非常默契。你可以非常方便地为 styled 组件添加类型定义，保证样式的调用安全。
例如：
interface ButtonProps {
primary?: boolean;
}
const Button = styled.button<ButtonProps>`
background: ${props => props.primary ? '#007bff' : '#fff'};
color: ${props => props.primary ? '#fff' : '#333'};
`;
TypeScript 会帮你检查是否漏掉了某个属性，或者错误地传递了类型，这对团队长期维护帮助巨大。
3. 调试工具一定要熟悉
Chrome DevTools 有个很有用的小技巧：在 Elements 面板中查看组件对应的样式时，你会看到类似这样的 class 名：
.sc-bwzfXH.kKtJmL
虽然看不懂，但是你可以点击右边的链接，跳转到 style 标签里面找到对应的样式定义。如果配合 Emotion 或 styled-components 的插件（如 emotion-devtools），还能看到组件名称映射关系，帮助定位问题。
4. 保持警惕：样式不要过度内联
有时候我们会为了图方便，把很多样式都直接 inline 写在组件里。这样其实不太好，会导致组件臃肿、可读性下降。
我建议的做法是：
- 把基础样式放在 styled component 中；
- 一些临时性、仅用于当前组件的简单样式可以直接写在里面；
- 但如果涉及到多个组件共享的样式片段，建议抽成单独的变量或函数进行复用；
- 复杂样式尽量写在外部模块中，方便统一管理和复用。
5. 主题系统设计可以前置考虑
如果你的项目未来可能会有多种 UI 主题（light/dark、白天/夜间模式），建议尽早规划主题系统。
Emotion 和 styled-components 都很好地支持主题系统，通过 ThemeProvider 可以统一注入主题变量：
<ThemeProvider theme={darkTheme}>
<App />
</ThemeProvider>
这样你就可以在整个应用中通过 props.theme.xxx 获取到主题配置，实现动态主题切换。
最后一句心里话
刚开始接触 CSS-in-JS 的时候，我也怀疑过：这不是又回到了“HTML 的 style 属性内联样式”时代吗？但实际用下来才发现，CSS-in-JS 是在现代前端架构下对样式管理的一次进化，而非倒退。
它解决了我们长期以来在组件化开发中遇到的痛点：如何让样式真正成为组件的一部分，而不是游离在外的附属品。
如果你现在正在为样式管理发愁，不妨试试 CSS-in-JS，也许它不能解决所有问题，但至少可以让你的开发流程变得更加愉快。
毕竟，写代码最重要的是开心，不是么？😄
如果你对某个具体的方案（比如 styled-components 和 Emotion 的比较）感兴趣，欢迎留言，我可以专门写一篇对比文章。
也欢迎你在评论区分享自己在样式管理方面的实践经验，我们一起探讨现代前端样式的最佳落地方式 💬
评论 0