CSS-in-JS vs 传统CSS：现代样式方案选择指南
CSS-in-JS vs 传统CSS：一个码农的风格焦虑日记
大家好，我是一个有着五年前端开发经验、头发日渐稀疏的普通程序员。最近几天，我一边盯着屏幕写着代码，一边在内心疯狂纠结一个问题：“到底是用传统CSS，还是尝试一把CSS-in-JS？”
事情要从上周说起。那是个阳光明媚的下午，我在公司接到了一个新的前端需求——重构我们平台的核心仪表盘页面。UI设计已经定稿，看起来挺清爽的，颜色分明，布局也比较复杂。这下问题就来了：项目原本使用的是传统的CSS加SCSS架构，结构清晰但有些混乱；而新加入的一位同事强烈推荐使用emotion这个CSS-in-JS方案。
“嘿，这玩意儿超方便，能动态控制样式，完全组件化，和React无缝结合，你试试看嘛！”他说这话的时候眼睛发亮，仿佛面前不是一行代码，而是一块刚出炉的提拉米苏。
我被说得有点心动，但也有一丝疑虑：传统CSS我已经熟得不能再熟了，为什么突然要换个思路？CSS-in-JS真的那么香吗？
初次试水CSS-in-JS，体验复杂又微妙
本着“开放的心态+技术人该有的探索欲”，我决定给CSS-in-JS一次机会。于是我打开了emotion的官网文档，准备迎接一场视觉与逻辑的碰撞。
第一眼看到写法是这样的：
const Button = styled.button`
background-color: ${(props) => props.primary ? 'blue' : 'gray'};
padding: 10px 20px;
`;
我心中一震：“这……不就是把CSS写在JavaScript里了吗？这不是倒退回十年前的那种style内联写法吗？”
但我还是硬着头皮写了几个组件。说实话，它的确带来了一些便利，比如：
- 组件化封装更自然：每个组件都有自己的样式定义，不需要去另外找对应的.scss文件。
- 状态驱动样式更容易实现：点击按钮换色、hover高亮这些交互直接通过props就能搞定，不需要再靠伪类选择器折腾半天。
- 命名冲突少了：传统CSS中最烦人的莫过于类名重复或作用域污染，而emotion这类库自动生成独一无二的class name，让我少了很多心理负担。
但与此同时，也有些地方让我感到不太适应：
- 写法风格怪异：习惯了写纯粹的CSS后，突然要在JS中写
styled.div、还要用模板字符串嵌入变量，刚开始真有点拧巴。 - 调试稍微麻烦些：原本DevTools中可以直接看类名查样式，现在生成的class都是随机的，需要多点几次才能找到对应元素。
- **性能是否靠谱？**虽然官方说优化过了，但在心里还是会嘀咕一下：“这样是不是有点杀鸡用牛刀？”
两套方案混用的尴尬期
为了稳妥起见，我打算先在仪表盘的几个关键组件上使用emotion，其他部分继续维持原CSS架构。结果没过两天，问题就来了。
首先，团队新人和我之间开始出现了“风格割裂”现象。他们负责的部分用了emotion，我的代码却还保留着SCSS模块化写法，合并到一起时，两种写法混杂在一起，就像西装革履的人和穿拖鞋短裤的人站一块，怎么看怎么别扭。
其次，构建时间变长了！可能是引入emotion带来的额外打包成本，整个项目的构建速度下降了一点。虽然不至于让人抓狂，但对于习惯追求极致效率的前端来说，总归是个小小的疙瘩。
最关键的是，当我试图复用旧的SCSS变量时，发现它们在emotion中并不能直接调用，还得重新维护一份主题配置文件，简直有种“分裂人格”的感觉……
转折：一个简单的提问，彻底改变了我的想法
那天开晨会时，产品随口问了一句：“这个按钮的主题色能不能让客户自己设置？”
这个问题像一道闪电劈中了我的脑袋。如果是原来的静态CSS，这事几乎等同于改代码重发布。但如果用CSS-in-JS呢？
我想了想，很快就在emotion基础上实现了动态主题功能。用户在界面上选个颜色，我通过context传递主题值，所有组件自动更新颜色。那一刻，我真的忍不住对旁边的同事竖了个大拇指：“emotional……确实很动人。”
这种灵活度和响应式的能力，确实是传统CSS难以企及的。
理性反思：它们其实没有谁更好，只有谁更适合
经历这一番折腾之后，我开始冷静下来思考：其实CSS-in-JS并不比传统CSS强多少，只是解决的问题不同罢了。
| 场景 | 更适合的方式 |
|---|---|
| 中小型项目 | 传统CSS/SCSS（学习成本低，结构成熟） |
| 大型组件化项目（如企业级应用） | CSS-in-JS（封装性强，主题灵活） |
| 需要大量动态样式变化（如编辑器、可视化工具） | CSS-in-JS |
| 需要SEO优先考虑的项目 | 传统CSS（服务端渲染兼容性更好） |
所以后来我也慢慢找到了一个平衡点：对于复杂的交互组件，使用emotion进行样式处理；而对于通用布局和基础样式，则依旧采用SCSS模块化管理。
给同行的一些建议
如果你也在面临这样的选择，不妨听我说几点建议：
- 不要盲目跟风。CSS-in-JS的确火了几年，但它不是银弹，也并非每个项目都需要。
- 根据团队技能来决策。如果你的团队成员都熟悉CSS，那就没必要为了潮流强行切换。
- 小步试错，逐步推进。可以先在局部组件中尝试CSS-in-JS，感受它的优劣后再决定要不要全面采用。
- 性能始终要关注。哪怕CSS-in-JS带来了便利，也要权衡它对构建速度和加载时间的影响。
- 保持开放的心态。技术本身并没有好坏之分，只有合适与否。今天的最佳实践，明天可能就被淘汰。重要的是持续学习和进化的能力。
写在最后：代码之外，还有审美
回顾这段从抗拒到接受的心路历程，我突然意识到：作为一个前端开发者，除了写出正确的代码外，我们还在追求一种“优雅”。这种优雅不仅仅是功能完美运行，更是代码结构整洁、易读、有美感。
无论是传统CSS还是CSS-in-JS，它们都是表达样式的语言，而真正的核心永远是我们如何将视觉与逻辑结合起来，创造出更好的用户体验。
也许未来哪天，又会出现什么新的样式方案，名字听着更酷、概念更炫，但只要它能帮助我更好地完成工作，我就愿意给它一次机会。
毕竟嘛，作为一个程序员，最重要的不是你会不会用某种技术，而是你是否敢于跳出舒适区，去尝试未知的东西。
如果你也有类似的经历或者想法，欢迎留言交流。让我们一起，在代码的世界里，走得更远一些。
评论 0