一次样式方案选型引发的“血案”
去年双11前夜，我正窝在工位上盯着 Spark UI 里那堆 shuffle spill 的红色警告，突然钉钉弹出前端同事的求助消息：“哥，我们新项目样式方案定不下来，CSS-in-JS 还是传统 CSS？你不是天天写代码吗，给点建议？”
我当时差点把咖啡喷屏幕上——我是大数据开发啊！每天和 Parquet、Delta Lake、K8s Operator 打交道，连 React 是啥都快忘了。但转念一想，咱们团队现在搞的是数据中台的前端看板，后端是我负责的，前端样式如果崩了，最后锅还得我背。再加上最近跳槽面试总被问“你怎么看待现代前端工程化”，索性咬咬牙，花了周末两天时间，从零撸了一遍两种方案的实战对比。
今天这篇，就是我在 GitHub 上折腾完 demo 后的真实复盘。别指望什么高屋建瓴的架构图，就一个普通码农的踩坑实录，希望能帮你少熬两个通宵。
事情是怎么开始的？
我们团队要重构内部数据治理平台的前端。老系统用的是纯 CSS + Bootstrap，样式散落在十几个 .css 文件里，改个按钮颜色能牵连出三个组件。产品经理上周五甩过来一句：“新版本要有暗色模式、动态主题切换，还要支持多租户品牌定制。”
我一听就头皮发麻。这需求放到三年前，可能得靠运维兄弟手动覆盖 CSS 变量，再配合 Nginx 多套静态资源分发。但现在？前端同学说社区有现成方案，比如 Emotion、Styled-components，或者 Tailwind CSS。可到底选哪个？没人敢拍板。
更惨的是 deadline 就在下个月底。隔壁组因为用了过时的 Ant Design 版本，导致 IE 兼容性炸了，整个双11大促页面白屏，项目经理差点当场辞职。这种事故我们可不敢碰。
于是，我这个“非专业前端”被迫营业，拉了个最小可行 demo 仓库（github.com/yourname/css-battle），准备亲自下场试毒。
传统 CSS：稳如老狗，但有点“老”
先说传统 CSS 方案。我们没用原生裸奔，而是上了 Sass + CSS Modules 组合拳。这是目前很多中大型项目的保守选择——毕竟兼容性好，构建工具链成熟，连我们公司老旧的 Jenkins 流水线都能跑。
快速上手，但作用域是个坑
一个典型组件长这样：
// Button.jsx
import styles from './Button.module.scss';
export default function Button({ children, variant = 'primary' }) {
return <button className={styles[variant]}>{children}</button>;
}
// Button.module.scss
.primary {
background: #1890ff;
color: white;
border: none;
padding: 8px 16px;
border-radius: 4px;
}
.secondary {
background: #f0f0f0;
color: #333;
}
看起来很清爽，对吧？但问题很快来了。
第一，全局污染虽避免了，但嵌套地狱没解决。
当我们要实现“悬停时子元素变色”这种交互，SCSS 写出来像俄罗斯套娃：
.card {
.header {
&:hover {
.title {
color: red;
}
}
}
}
第二，动态主题？难搞。
产品经理要的“暗色模式”，意味着同一套样式要有两套值。传统做法是搞两份 CSS 文件，通过 class 切换：
<body class="dark-theme">
.light-theme {
--bg-color: #fff;
}
.dark-theme {
--bg-color: #121212;
}
但这样变量管理分散，维护成本高。而且一旦用户切换主题，浏览器得重新解析整份 CSSOM，性能堪忧——尤其是在我们这种动辄上百个组件的数据看板里。
CSS-in-JS：灵活到飞起，但代价不小
转战 CSS-in-JS 阵营，我选了 Emotion（比 Styled-components 轻量，且支持 SSR）。它的核心思想是：样式即 JavaScript。
同样一个按钮：
import { css } from '@emotion/react';
const buttonStyles = (theme) => css`
padding: 8px 16px;
border-radius: 4px;
background: ${theme.primaryColor};
color: white;
border: none;
`;
export default function Button({ children }) {
return <button css={buttonStyles}>按钮</button>;
}
配合 ThemeProvider，主题切换变得极其优雅：
// App.jsx
import { ThemeProvider } from '@emotion/react';
const lightTheme = { primaryColor: '#1890ff' };
const darkTheme = { primaryColor: '#177ddc' };
function App() {
const [theme, setTheme] = useState('light');
return (
<ThemeProvider theme={theme === 'light' ? lightTheme : darkTheme}>
<Dashboard />
</ThemeProvider>
);
}
真香时刻：动态 & 条件样式
最让我惊艳的是基于 props 动态生成样式的能力。比如根据数据状态改变卡片颜色：
const cardStyle = (status) => css`
background: ${status === 'error' ? '#ffebee' : '#e8f5e9'};
border-left: 4px solid ${status === 'error' ? '#f44336' : '#4caf50'};
`;
再也不用在 className 里拼字符串了！以前为了 isActive && 'active' 这种逻辑，我见过有人写出三元运算符嵌套三层的“艺术代码”。
但！性能和打包体积翻车了
然而，上线前压测时，前端同学发现首屏加载慢了近 400ms。查了 Webpack Bundle Analyzer，发现 @emotion/react 相关代码占了 120KB（gzip 后）。而我们的传统 CSS 方案，所有样式压缩后才 60KB。
更致命的是运行时开销。Emotion 在组件渲染时会动态注入 <style> 标签。当页面有 50+ 图表组件（每个带 tooltip、legend 等子元素），Chrome DevTools 的 Performance 面板直接爆红——大量 Recalculate Style 和 Layout Thrashing。
有一次测试环境部署后，我打开页面发现 CPU 占用飙到 90%，风扇狂转。当时真想砸电脑。后来才知道，是因为某个循环渲染的列表没加 key，导致 Emotion 重复创建 style rules。
关键对比：资源、维护性、性能
我把核心维度拉了个表格，方便大家快速决策：
| 维度 | 传统 CSS (Sass + Modules) | CSS-in-JS (Emotion) |
|---|---|---|
| 学习曲线 | 低（前端基础技能） | 中（需理解 JS 闭包、缓存） |
| 主题切换 | 需手动管理 CSS 变量或多文件 | 原生支持，代码简洁 |
| 动态样式 | 依赖 className 拼接，易出错 | 直接内联，逻辑清晰 |
| 打包体积 | 小（纯文本，可 gzip） | 较大（含运行时库） |
| 运行时性能 | 高（浏览器原生解析） | 中（JS 注入 + 样式计算） |
| 调试体验 | Chrome DevTools 直接定位 | 需熟悉 data-emotion 属性 |
| 服务端渲染 (SSR) | 天然支持 | 需额外配置 extractCritical |
| 团队协作 | 设计师可直接给 CSS | 需前端介入转换 |
特别提一下 资源消耗。我们在 K8s 集群上跑前端应用，内存限制 512MB。CSS-in-JS 方案在高并发场景下，Node.js 内存占用比传统方案高约 15%——虽然不至于 OOM，但运维同学看到监控告警还是会半夜打电话。
我们最终怎么选的？
经过两周的 AB 测试（是的，连样式方案都要 A/B Test），结合团队现状，我们做了个“混合策略”：
基础组件库（Button, Card, Form）：用 Tailwind CSS
为什么？因为它本质是“原子化传统 CSS”。通过@apply把常用样式组合成语义化 class，既避免了命名污染，又保留了原生 CSS 性能。而且设计师给的 Figma 标注能直接对应text-sm p-2 bg-blue-500，沟通成本大降。复杂业务组件（图表、数据表格）：用 Emotion
这些组件需要大量基于数据的动态样式（比如柱状图颜色随数值变化），CSS-in-JS 的表达力无可替代。但我们加了严格规范：- 所有样式函数必须 memoize
- 禁止在 render 函数内定义 css
- 使用
cssprop 而非 styled()
// ✅ 正确：memoized 样式
const getChartStyle = memoize((value) => css`
background: ${value > 0 ? 'green' : 'red'};
`);
// ❌ 禁止：每次渲染都新建函数
<div css={css`color: ${theme.color};`}>...</div>
上线后，首屏性能回到可接受范围（FCP < 1.2s），主题切换丝滑，产品经理终于没再找茬。
给同行的几点血泪建议
别盲目追新
CSS-in-JS 不是银弹。如果你的项目不需要动态主题、没有复杂交互，老老实实用 Sass + CSS Modules 更稳妥。我们组有个内部工具项目，至今还是纯 CSS，跑得飞快。重视调试体验
传统 CSS 在 DevTools 里点两下就能改样式实时预览。而 Emotion 生成的 class 名像css-1a2b3c，得靠插件（如 Emotion DevTools）才能映射回源码。新人上手容易懵。关注构建产物
用 Webpack Bundle Analyzer 定期检查样式相关体积。我们曾因忘记配置 Emotion 的sourceMap: false，导致生产包多了 30KB 无用 sourcemap。善用社区资源
GitHub 上有大量优质教程和 starter kit。比如：- vercel/styled-system：基于 props 的响应式设计系统
- tailwindlabs/tailwindcss：官方文档堪称教科书
- 我的 demo 仓库也开源了：css-battle，包含完整配置和性能测试脚本
和设计师对齐工作流
如果设计师用 Figma，推荐插件 Zeroheight 或 Supernova，能把设计 token 自动转成 CSS 变量或 JS 对象，避免“你做的和设计稿差 2px”这种撕逼。
写在最后：代码人生，没有标准答案
回望这次样式方案之争，其实没有绝对的对错。就像我们大数据领域，Spark 和 Flink 也各有适用场景。关键在于理解业务约束、团队能力和技术债容忍度。
作为天天和 Spark 打交道的人，我反而从这次前端折腾中学到了重要一课：工程决策的本质，是在“理想”和“现实”之间找平衡点。你可以追求最酷的技术，但别忘了凌晨三点被线上报警叫醒的痛苦。
如果你也在纠结 CSS-in-JS 还是传统 CSS，不妨问问自己：
- 我的团队是否愿意为灵活性付出性能代价？
- 产品是否真的需要动态主题？
- 有没有人能长期维护这套样式体系？
答案清楚了，选择自然就出来了。
哦对了，刚收到前端同事消息，说产品经理又提了新需求：“能不能根据用户心情自动切换主题颜色？”…… 我默默打开了 Emotion 文档，看来这周又得加班了。
本文所有代码示例和配置已上传 GitHub：github.com/yourname/css-battle
觉得有用？给个 star 支持一下，你的鼓励是我继续写“非专业前端”文章的动力 😅
评论 0