去年某个凌晨，一位前端工程师在GitHub上删掉了自己维护三年的CSS-in-JS库。理由是：浏览器原生支持的嵌套语法，终于让他意识到自己一直在用火箭炮打蚊子。
这件事没上热搜，但在技术圈炸了。不是因为情绪，是因为数字——有人实测迁移后代码量少了47%，构建时间从14秒降到3秒。
「解决方案」制造的问题比解决的还多
CSS领域有个怪现象：每过两年就有人宣布发现了「终极方案」。CSS Modules、Styled Components、Tailwind、原子化CSS……它们确实解决了一些问题，但代价是把你拖进另一套复杂度。
原作者说得直白：「它们解决的大部分问题，只存在于作者自己的气泡里。」
气泡是什么？是假设你会写出全局污染严重的代码，是假设你的团队管不住命名规范，是假设构建工具链越厚越好。这些假设成了自我实现的预言——你越用复杂工具，越觉得复杂工具必要。
有个细节很讽刺：很多团队引入CSS-in-JS是为了「隔离样式」，结果调试时要在浏览器里追三层生成的随机类名，反而更难定位问题。
原生嵌套语法到底改变了什么
2023年，所有主流浏览器完成了对CSS嵌套（Nesting）的支持。这不是新发明，是把SASS用了十几年的结构搬进了标准——但关键区别是：零构建步骤，零运行时开销。
写法长这样：
.semantic-component-name-here { color: var(--theme-color, #ccc); input[type="submit"] { background: blue; } }
外层类名作为命名空间，内部用标签选择器或后代选择器自由展开。容器查询、变量继承、媒体查询——全部原生支持，全部零额外依赖。
原作者的组件文件结构更简单：一个HTML文件，一个CSS文件，类名就是组件名本身。没有哈希后缀，没有运行时注入，没有JavaScript参与样式计算。
这种结构有个隐性好处：调试时你看到的选择器，和源代码完全一致。浏览器开发者工具里的样式面板，终于不再是加密文本。
为什么有人拼命反对「删掉未使用CSS」
文章里埋了一个反常识观点：不要在构建时清除未使用的CSS类。
这听起来像异端。Purging不是性能优化的标准动作吗？
原作者的逻辑是：如果你按组件组织文件，每个组件的CSS只加载一次，未使用的类根本不会被请求。所谓的「冗余」只存在于你想象的全量打包场景——而那个场景是你自己用工具链设计出来的。
「不要设计你的代码去成为问题，然后卖解决方案。」
这个判断有前提：你的项目确实按组件拆分了样式，而不是一个巨大的全局CSS文件。但讽刺的是，很多引入PurgeCSS的团队，恰恰是因为之前的架构决策让样式成了全局灾难。
Svelte的折中路线值得细看
原文提到Svelte的部分做了些修正：它确实会给组件加随机ID实现作用域，但编译时就把样式抽成静态CSS，没有运行时负担。
这和其他框架的CSS-in-JS有本质区别。Styled Components要在客户端动态生成类名，Svelte在构建时就做完了。用户收到的还是普通CSS文件，只是选择器带了哈希后缀。
原作者的评价是「最接近正确做法的现成方案」，但补了一句：「不如自己直接做。」
这个「不如」背后是对控制权的执念。当你依赖框架的编译策略，就接受了它的命名规则、它的拆分粒度、它的缓存策略。而原生嵌套语法让你在所有这些决策上保留自由度。
迁移成本被严重低估了吗
反对声音集中在一点：存量项目怎么迁？
这不是技术问题，是算账问题。一个运行五年的后台系统，样式层已经和技术债融为一体，迁移ROI确实可能为负。但新项目、新模块、新组件呢？
原文的立场很清晰：不是让你明天就重构所有代码，是让你停止在新代码里制造本可避免的问题。
有个数据点来自Vercel团队内部：他们把新组件逐步切到原生嵌套后，构建缓存命中率提升了，因为CSS文件不再被JavaScript的改动频繁触发重新编译。
这种收益不会出现在任何性能监控仪表盘上，但每天省下的几十秒累积起来，是真实的时间成本。
你现在打开自己项目的node_modules，统计一下CSS相关的依赖数量。再问自己：这些工具解决的是浏览器做不到的事，还是你假设自己会做错的事？
热门跟贴