CSS-in-JS vs 传统CSS：现代样式方案选择指南
上周五晚上，我坐在成都玉林路的小酒馆旁，手边一杯冰美式（创业后咖啡因摄入量飙升），翻着 GitHub 上一个新项目的 PR。突然看到团队里有个 junior 同学在用 styled-components 写按钮样式，而隔壁模块还在用老派的 .btn-primary + BEM 命名。那一刻我恍惚了——这不就是去年我在前司带团队时天天吵架的话题吗？
对，没错，我是那个已经从大厂技术总监岗位裸辞、正在捣鼓自己 SaaS 产品的“前浪”。坐标成都，生活节奏舒服得让人想躺平，但代码洁癖一点没减。Vim 党，.vimrc 比女朋友还熟；写代码可以慢，但可读性和可维护性必须拉满——毕竟以后要靠这玩意吃饭。
今天就想聊聊 CSS-in-JS 和 传统 CSS 这对“冤家”。这不是一篇教科书式的对比，而是来自一线血泪的经验总结。尤其最近好多朋友在准备跳槽，这题简直是高频 面试题挑战 ——“你们项目为什么选 CSS-in-JS？”、“传统 CSS 有什么不可替代的优势？” 答不好，HR 可能直接把你简历扔进回收站。
起因：一个“简单”的产品需求
事情得从去年双11说起。当时我们接了个紧急需求：给电商后台加个“实时库存预警”弹窗。产品经理画了个 Figma，说“就按 Ant Design 风格来，但颜色要动态适配商家主题色”。
乍一听很简单，对吧？但坑就埋在这句“动态适配”里。
传统做法？写一堆 CSS 变量，或者用 JS 动态改 <style> 标签。但问题是，这个弹窗是微前端架构下的独立模块，不能污染全局样式。更糟的是，测试同学反馈：在 IE11（别笑，真有客户用）上样式全崩，而且切换主题时偶尔闪白屏。
我当时真的想砸键盘——不是因为难，是因为维护成本太高。三个开发，两天时间，一半在调样式优先级和 !important 战争。
后来我一咬牙：试试 CSS-in-JS 吧。
实战：Styled Components 上线记
我们选了 styled-components（别杠，Emotion 也行，原理类似）。核心思路就一条：把样式和组件绑定，避免全局污染，支持运行时动态注入。
// components/StockAlert.js
import styled from 'styled-components';
const AlertBox = styled.div`
background: ${props => props.theme.warningBg || '#fff3cd'};
border: 1px solid ${props => props.theme.warningBorder || '#ffeaa7'};
color: ${props => props.theme.warningText || '#856404'};
padding: 12px;
border-radius: 4px;
font-size: 14px;
transition: all 0.2s ease;
&:hover {
transform: translateY(-2px);
box-shadow: 0 2px 8px rgba(0,0,0,0.15);
}
`;
export default ({ stock, theme }) => (
<AlertBox theme={theme}>
⚠️ 库存仅剩 {stock} 件！
</AlertBox>
);
看明白没？样式直接内联到组件，theme 从 props 传入，动态值直接插值。再也不用担心 .alert-warning 被其他模块覆盖，也不用手动管理 class 切换。
效果立竿见影：
- 主题切换无闪烁（因为样式是 JS 渲染的一部分）
- 微前端隔离完美（每个实例自带 scoped 样式）
- 删除组件 = 自动清理样式（不用手动删 CSS 文件）
但代价也有：首屏加载多了 ~15KB 的 runtime（gzip 后），而且 SSR 配置差点让我秃头。不过对我们这种内部管理系统，用户体验 > 极致性能，值得。
踩坑实录：那些没人告诉你的细节
1. 性能陷阱
CSS-in-JS 在动态生成大量样式时（比如数据表格每行不同颜色），可能触发频繁的 style 标签插入。我们曾在线上遇到过，1000 行表格滚动卡成 PPT。
解法：用 css helper 提前编译静态部分，动态部分尽量复用：
const rowStyle = css`
&:nth-child(even) { background: #f9f9f9; }
`;
const DynamicRow = styled.tr`
${rowStyle}
background-color: ${props => props.highlight ? '#fff9c4' : 'white'};
`;
2. 调试噩梦
浏览器 DevTools 里看到的全是 sc-AxirZ 这种鬼名字。还好 styled-components 支持 displayName，加上后 DevTools 会显示组件名：
// .babelrc
{
"plugins": [
["styled-components", { "displayName": true }]
]
}
3. IE 兼容性
别信“CSS-in-JS 不支持 IE”的谣言。styled-components v5+ 通过 @emotion/is-prop-valid 自动过滤非法属性，IE11 能跑（但别指望 CSS Grid）。不过如果你的产品必须支持 IE8……兄弟，建议你直接辞职。
对比表格：什么时候该用谁？
| 维度 | 传统 CSS (SCSS/BEM) | CSS-in-JS (Styled Components/Emotion) |
|---|---|---|
| 作用域 | 全局（需靠命名规范隔离） | 组件级自动隔离 |
| 动态主题 | 需 CSS 变量 + JS 控制 | 原生支持 props/theme |
| Bundle Size | 无额外 runtime | +10~20KB (gzip) |
| SSR 支持 | 天然友好 | 需额外配置（如 collectStyles） |
| 调试体验 | DevTools 直接看 class | 需开启 displayName |
| 学习曲线 | 前端必修课 | 需理解 JS 闭包/模板字符串 |
| 适合场景 | 静态页面、高兼容性要求、极致性能 | 动态 UI、微前端、React/Vue 组件库 |
我的建议：别站队，看产品
很多技术争论最后都变成了宗教战争。但作为过来人，我想说：没有银弹，只有权衡。
- 如果你在做 企业级后台系统（比如我们的库存预警），用户少、迭代快、需要动态主题 → CSS-in-JS 是甜点。
- 如果你在做 高流量营销页（比如双11主会场），首屏性能生死线 → 传统 CSS + Critical CSS 更稳。
- 如果你在写 开源组件库（比如 Ant Design）→ 两者混合：核心用 CSS，提供 CSS-in-JS 封装层。
顺便说一句，最近面试时我常问候选人：“如果让你重构一个用了 5 年的老项目，你会把 CSS 全换成 CSS-in-JS 吗？”
答“当然换”的，我基本不考虑——技术选型不是炫技，是为产品服务。
结语：工具而已，别被绑架
写完这篇，窗外成都的夜雨刚停。回想当年在大厂，为了“技术先进性”强行上 CSS-in-JS，结果上线后运维抱怨 bundle 太大，测试抱怨样式难定位，产品经理抱怨改个颜色要等构建……现在想想，真是年少轻狂。
创业后反而清醒了：代码是手段，不是目的。用户不在乎你用 SCSS 还是 Emotion，他们只在乎按钮点下去有没有反应，页面加载快不快。
所以，下次再遇到“CSS-in-JS vs 传统 CSS”的 面试题挑战，别背八股文。告诉面试官：“看产品阶段、看团队能力、看用户场景——我的原则是，能用最简单方式解决问题的方案，就是好方案。”
对了，我新做的 SaaS 产品下个月内测，用的是 Tailwind + 少量 CSS-in-JS 混合方案。为啥？因为老板（也就是我）既要快速原型，又要保证后期可维护性啊！
（完）
P.S. Vim 党友情提示：写 styled-components 时记得装
vim-styled-components插件，不然语法高亮会疯掉。别问我怎么知道的。
评论 0