CSS-in-JS 真的香吗？我在 React 项目里踩过的样式方案大坑
上个月，我们团队接了个新需求：把公司主站的营销页全重构一遍，要求加载快、动画流畅、适配各种奇葩分辨率——最关键的是，下周五上线。作为组里唯一一个对前端动效有点执念的“老”人（其实也就三年工龄），这活儿自然落到了我头上。
彼时我正窝在出租屋的沙发上远程办公，一边啃着冷掉的外卖，一边翻看旧代码。看着满屏的全局 class 名和神秘的 !important，突然意识到：是时候认真思考一下我们的样式管理策略了。传统 CSS 还能撑多久？CSS-in-JS 到底是不是银弹？这篇文章，就是我在 deadline 压力下踩坑、试错、最终做出选择的真实记录。
起因：一次“简单”的重构差点让我原地爆炸
事情起于产品经理一句轻描淡写的话：“这次页面要支持动态主题切换，比如白天/黑夜模式，还要能根据不同活动换皮肤。”听起来很酷，对吧？但当我翻开现有代码，发现所有样式都写在 .scss 文件里，靠 BEM 命名勉强维持秩序，组件之间还存在大量隐式依赖——改一个按钮颜色，可能让整个表单布局崩掉。
更惨的是，我们用的是 React + Webpack + Sass 的经典组合，没有做任何 CSS 模块化。每次发版，运维兄弟都要小心翼翼地清缓存，因为上次就因为一个类名冲突，导致用户登录按钮变成了透明色，整整两小时没人能登录……
于是，我开始调研现代样式方案。主流无非两条路：传统 CSS 的演进路线（如 CSS Modules、Sass + BEM），和 CSS-in-JS 路线（如 styled-components、Emotion）。作为一个喜欢折腾新技术的人，我一度觉得 CSS-in-JS 是未来，直到自己亲手埋了几个雷。
CSS-in-JS 的诱惑与陷阱
先说优点，真的香：
- 作用域天然隔离：每个组件的样式只属于它自己，再也不用担心命名冲突。
- 动态样式超方便：配合 React 的 props，写条件样式简直行云流水。
- 主题切换轻松实现：通过 Context 注入 theme 对象，一行代码搞定深色模式。
我兴冲冲地在新项目里引入了 styled-components，写出了这样的代码：
// components/Button.jsx
import styled from 'styled-components';
const StyledButton = styled.button`
background: ${props => props.theme.primary};
color: white;
border: none;
padding: 8px 16px;
border-radius: 4px;
cursor: pointer;
transition: background 0.2s;
&:hover {
background: ${props => props.theme.primaryDark};
}
`;
看起来很优雅，对吧？本地开发跑得飞快，动画也顺滑。可当我把代码推到测试环境，性能监控工具突然报警：首屏 FCP（First Contentful Paint）比之前慢了近 300ms！
排查半天才发现，styled-components 在运行时会动态生成 <style> 标签并插入 DOM。虽然它做了缓存，但在 SSR（服务端渲染）场景下，如果没正确配置，会导致样式重复注入或水合（hydration）不一致。我们用的是 Next.js，但团队为了“快速上线”跳过了 SSR 配置优化，结果客户端还得重新计算一遍样式。
更糟的是，某次线上发布后，iOS Safari 上的按钮文字居然显示不全！原因是动态生成的 class 名太长（比如 sc-hKgILt jXaYdE），而 Safari 对 selector 长度有隐性限制（虽然官方没写）。这种玄学 bug 调试起来真的想砸键盘。
回归传统？CSS Modules 的稳重之道
被坑了一次后，我冷静下来，重新评估了团队现状：
- 项目迭代快，新人多，需要低学习成本
- SEO 有要求，必须做好 SSR
- 不希望引入太多运行时开销
于是，我把目光投向了 CSS Modules + Sass 的组合。没错，就是那个“老派”方案。
改造后的代码长这样：
/* Button.module.scss */
.button {
background: var(--primary);
color: white;
border: none;
padding: 8px 16px;
border-radius: 4px;
cursor: pointer;
transition: background 0.2s;
&:hover {
background: var(--primary-dark);
}
}
// Button.jsx
import styles from './Button.module.scss';
export default function Button({ children }) {
return <button className={styles.button}>{children}</button>;
}
虽然少了点“炫技感”，但好处立竿见影：
- 零运行时开销：样式在构建时就确定了，打包成静态 CSS 文件，浏览器直接缓存。
- SSR 天然友好：Next.js 自动提取关键 CSS，首屏加载速度回到正常水平。
- 调试清晰：DevTools 里看到的就是
Button_button__abc123，一眼知道来源。
而且，配合 CSS 变量，主题切换也能实现：
// theme.js
export const setTheme = (mode) => {
document.documentElement.style.setProperty('--primary', mode === 'dark' ? '#1a1a1a' : '#007aff');
document.documentElement.style.setProperty('--primary-dark', mode === 'dark' ? '#333' : '#0056b3');
};
虽然不如 CSS-in-JS 那么“React 化”，但胜在稳定、可预测。
综合对比：没有银弹，只有合适
经过这两轮折腾，我整理了一个简单的对比表，供大家参考：
| 维度 | CSS-in-JS (styled-components) | 传统 CSS (CSS Modules + Sass) |
|---|---|---|
| 作用域隔离 | ✅ 自动 | ✅ 通过哈希类名 |
| 动态样式 | ✅ 极其方便 | ⚠️ 需配合 CSS 变量或 JS 动态 class |
| SSR 支持 | ⚠️ 需额外配置 | ✅ 开箱即用 |
| 运行时性能 | ❌ 有开销 | ✅ 零开销 |
| 调试体验 | ⚠️ class 名难读 | ✅ 类名可读性强 |
| 学习成本 | ⚠️ 需理解新概念 | ✅ 熟悉 CSS 即可 |
| 主题切换 | ✅ 原生支持 | ✅ 配合 CSS 变量 |
关键结论：如果你的项目重度依赖动态样式、追求极致的组件封装，且团队能 handle 运行时成本，CSS-in-JS 很香。但如果你更看重性能、稳定性、SEO，或者团队里有刚转前端的同学，传统 CSS 方案依然是更稳妥的选择。
我的最终选择：混合策略
现实往往不是非黑即白。我现在采用的是混合策略：
- 通用组件库（如 Button、Modal）：用 CSS Modules + Sass，保证性能和一致性。
- 高度动态的营销页组件（如带动画的 banner、交互式图表）：用 Emotion（比 styled-components 更轻量，支持 zero-runtime 模式）。
- 主题系统：统一用 CSS 变量管理，无论底层用哪种方案都能接入。
上周五晚上，就在 deadline 前一天，我终于把新页面上线了。首屏加载时间从 2.1s 降到 1.3s，Lighthouse 性能分从 68 提升到 92。产品经理发来微信：“效果不错，下周再加个粒子动画？” —— 我默默关掉了聊天窗口，打开了《动物森友会》。
写在最后
技术选型没有绝对的对错，只有是否适合当前团队和项目阶段。CSS-in-JS 并不是洪水猛兽，传统 CSS 也不是过时古董。作为一线开发者，我们要做的不是盲目追新，而是在综合考量性能、维护性、团队能力后，做出最务实的选择。
毕竟，能准时下班、少修线上 bug 的方案，才是好方案。你说呢？
（P.S. 如果你也在用 React 做性能优化，欢迎留言交流！我最近还在研究如何用 requestAnimationFrame 优化复杂动画，下次或许可以聊聊～）
评论 0