如果你是一名前端开发者，特别是React开发者。你一定听说过或使用过CSS-in-JS方案。从Styled-components到Emotion。这些库在短短几年内迅速流行，被无数项目采用。

但今天我要冒着被喷的风险说一句：CSS-in-JS是个糟糕的设计。它解决了不出现的问题，却创造了真实的新问题。不过，

一、CSS-in-JS的“美好”承诺

支持者们会告诉你CSS-in-JS有多棒：

• 组件化样式与组件绑定。不再担心样式污染
• 动态样式基于props的动态样式轻而易举
• 自动处理前缀不再需要手动写-webkit-
• 代码简洁不再需要在不同文件间跳转

听起来很美好，不是吗？其实，但这些“好处”背后隐藏着巨大的代价。

二、现实中的七宗罪

至于运行时开销，性能的隐形杀手

CSS-in-JS在运行时解析样式、生成类名、注入到文档中。话说回来，这代表着使用者访问你的网站时JavaScript必须完成这些额外工作才能显示样式。

对比一下：

• 传统CSS浏览器直接解析和应用样式
• CSS-in-JSJavaScript执行 → 解析样式 → 生成类名 → 注入样式 → 浏览器应用

在慢速设备或网络条件下这种差异尤为明显。而这一切，只是为了实现原本浏览器原生就能处理的事情。

体验的倒退

“在JavaScript中写CSS”听起来很酷，直到你真正开始使用：

const Button = styled.button` background: ${props => props.primary?'blue' : 'white'};color: ${props => props.primary?'white' : 'blue'};按理说，&:hover { background: ${props => props.primary?'darkblue' : 'lightgray'};} @media { font-size: 14px;padding: 8px 16px;}`，

这段代码里你失去了：

• CSS语法高亮
• CSS自动补全
• CSS linting检查
• 浏览器DevTools的直接编辑能力

可维护性噩梦

当样式逻辑复杂时你最终会得到这样的代码：

const ComplexComponent = styled.div` ${ => { // 一大堆JavaScript逻辑 let styles = '';
if { styles += `background: ${me.colors.primary};`，怎么说呢，} if { styles += `padding: 20px;font-size: 18px;`，} if { styles += `opacity:;cursor: not-allowed;`，} return styles;}}>`，

这不再是“在JS中写CSS”，而是“用JS逻辑生成CSS字符串”。可读性和可维护性急剧下降。

学习成本陡增

新开发者需要学习：

1. CSS本身
2. JavaScript
3. React
4. 特定CSS-in-JS库的语法和API
5. 如何调试这个独特的程序

而他们学到的大多数知识，在离开这个特定技术栈后毫无用处。

SSR和静态生成的复杂性

服务器端渲染变得复杂：

• 需要收集使用的样式
• 需要在HTML中注入样式
• 需要处理hydration不匹配
• 增加了包大小和内存使用

而这一切对于纯CSS都是不存在的。话说回来，

调试困难

在浏览器DevTools中。你会看到这样的类名：.sc-1a2b3c4d .想根据类名找到对应的组件？祝你好运，

想了解某个样式来自哪个组件？至于你需要，

1. 打开DevTools

找到元素

查看混乱的类名

在代码中搜索这个生成的类名

或者安装专门的浏览器

CSS-in-JS试图解决的问题。其实有更方案：

从方案一来看，CSS Modules

/* Button.module.css */.button { background: blue;其实，color: white;}.primary { background: darkblue;}.button:hover { background: lightblue;老实说，}

import styles from './Button.module.css';老实说，function Button { return;}

优点

• 真正的局部作用域

零运行时开销

保持CSS原生能力

易于调试

---