CSS-in-JS vs 传统CSS：现代样式方案选择指南
CSS-in-JS vs 传统CSS：现代样式方案选择指南
一、开篇：从一段深夜调试开始的故事
那天晚上，我坐在电脑前，屏幕上是两行代码的对比：
// CSS-in-JS 的 styled-components 写法
const Button = styled.button`
background: #4CAF50;
border: none;
padding: 10px 20px;
color: white;
`;
// 传统CSS写法
<button class="primary-button">点击</button>
.primary-button {
background: #4caf50;
border: none;
padding: 10px 20px;
color: white;
}
我的眼睛酸得不行，键盘上还残留着几颗咖啡渍。项目快上线了，但 UI 部分却让我越来越焦虑。我们用的是 styled-components，一开始看起来很优雅、组件化强，但在协作过程中却出现了不少“意料之外”的麻烦。
我记得那天凌晨两点，我在 Slack 上收到设计师的一条消息：“按钮的颜色好像和设计稿不一致啊。”
我说：“奇怪了，我明明设了 #4CAF50 啊……”
再一看浏览器 DevTools，发现这个颜色被某个“动态注入的 style 标签”悄悄地覆盖了……
那一刻，我突然意识到一个现实的问题——在这个技术选择越来越多的时代，我们到底该怎么选择合适的样式方案？
二、经历：从热爱到迷茫
刚入行那会儿，我也是个纯粹的传统派。
那时候用 Sass、BEM、Less，每一个组件都有一套命名规则，像写诗一样严谨又优美。“btn-primary”、“menu--expanded”，这些类名就像程序员的语言密码，只有懂的人才明白其中逻辑。
后来 React 火了起来，CSS-in-JS 也逐渐兴起。第一次看到 styled-components 这种写法时，我内心是震撼的：
“原来样式可以直接写在 JS 文件里，还能直接读取 props？”
那种感觉，就像突然拿到了一把瑞士军刀。它把样式和组件绑在一起，不再需要跳来跳去查找 CSS 文件。而且，热加载让开发体验流畅无比。
于是我们团队决定尝试一次大的重构，全部转向 CSS-in-JS。
刚开始真的很爽，组件即样式，逻辑清晰、结构紧凑，甚至可以动态生成样式，简直是“组件驱动开发”的终极解决方案。
可没过几个月，事情就变得复杂了。
- 组件嵌套多了之后，样式难以复用。
- 某些库在 SSR（服务端渲染）下表现异常。
- 浏览器中多个
<style>标签混乱不堪。 - 团队新人很难理解这种“内联式”写法。
- 最可怕的是——性能问题悄然出现：页面加载变慢了，尤其是在大量使用动态样式时。
那次上线后，用户反馈说首页卡顿明显。我们翻查资源加载瀑布图，发现有几十个 <style> 被注入，全是来自那些“随心所欲”的 styled-components 实例。
我们陷入了深深的反思。
三、感受：技术不是工具，而是一种责任
我记得有一天中午吃饭的时候，组里的老前端王哥对我说：
“技术选型从来都不是‘哪个酷’，而是‘谁更稳定、更容易维护’。”
这句话像钉子一样扎进了我心里。
我开始重新审视自己对技术的态度。曾经，我沉迷于新技术带来的新鲜感，喜欢用别人没用过的库，追求炫酷的实现方式。但现在我明白了：作为程序员，我们的工作不仅仅是写出能跑的代码，更重要的是让它在几年后依然有人愿意接手、能够读懂、方便扩展。
我开始认真研究各种样式方案的本质区别。
四、转折：从对抗到融合
转机出现在一次 Code Review 上。
那天我们组要解决一个复杂的布局问题，涉及到响应式断点、主题切换、以及大量的状态样式变更。我提出了一个大胆的想法：
“为什么不混合使用呢？基础结构用 SCSS 写全局样式，局部交互用 styled-components 动态控制？”
大家一开始都有点迟疑，但当我画出具体的组织结构图，说明哪里该分离、哪里该封装时，整个团队开始慢慢理解我的思路。
最终，我们达成了一致——不再“非此即彼”，而是根据场景“按需使用”。
例如：
- 全局样式、字体、网格、动画统一用 PostCSS + SCSS 处理。
- 组件层级内的状态样式、动态计算值用 styled-components 来增强灵活性。
- 对于特别注重性能的页面（如登录页），则完全使用传统的 className + CSS Modules。
- 所有样式最终走构建流程优化压缩，并用 linting 工具统一规范。
这套组合拳打出来之后，不仅开发效率提高了，项目的可维护性也增强了。
最欣慰的是，新来的实习生看着结构清晰的目录，居然笑着说：“你们的代码好干净啊。”
五、思考：写给其他前端兄弟的一封信
如果你也在纠结应该用哪种方案，我想分享几点心得，可能帮不到所有人，但我希望你至少知道，你在面对的选择题并不是一个人在战斗。
没有银弹，只有权衡。
CSS-in-JS 和传统 CSS 各有千秋。前者适合高度封装的组件体系，后者更适合大型应用的基础样式管理和团队协作。不要盲目跟风。
别因为某个框架火了就全盘照搬。问问自己几个问题：- 我们的应用规模多大？
- 是否需要 SSR 或静态导出？
- 团队是否有熟悉 CSS-in-JS 的人？
- 性能要求高不高？
保持开放的心态。
技术在变化，但核心能力不会变。比如对盒模型的理解、对层叠与优先级的掌握、对响应式设计的敏感度……无论你怎么写样式，这些才是真正的基本功。建立一套自己的判断标准。
别人的经验只能参考，真正合适的方式，还得靠你在实际项目中去验证。多试错几次没关系，关键是每一次都要总结。
六、展望：愿每一段代码都有温度
如今，我已经习惯在项目初期就制定一套合理的样式架构策略。
我会根据产品形态、团队背景、未来扩展性来决定是否使用 CSS-in-JS，或者混合使用。
我也学会了不在朋友圈里秀“用了什么高大上的新技术”，而是更多地去讲“为什么这么用”。
因为我终于明白，写代码不仅是写给机器看的，更是写给人看的，偶尔也顺便运行一下而已。
有时候，我会翻看以前写的 CSS 文件，看着那段略显笨拙却整齐划一的 BEM 类名，心里竟有些感动。
那段时光教会了我克制、耐心与坚持；而现在的我，则学会了包容、灵活与创新。
也许哪一天，Web Components 会彻底改变样式生态，也许新的 CSS 模块机制会横空出世。
但不管怎样，在这不断变化的技术世界里，我希望我们始终保有一个共同的目标：用最合适的工具，写出最有温度的代码。
结语
亲爱的同行者们，愿你在每一个深夜调试 bug 的时候，不只是想着如何让它“跑起来”，而是想得更远一点——
“这段代码，会不会成为下一个接手它的同事眼中的光？”
评论 0