CSS-in-JS vs 传统CSS：一个相亲N次终于脱单的北京程序员的血泪选择指南
去年十月的一个周五晚上，我坐在天通苑13号线地铁口旁那家开了十年、连WiFi都连不上三次的咖啡馆里，对面是个穿浅蓝色高领毛衣、自称“对技术有热情”的姑娘。她问我：“你是做什么的？”
我说：“写前端的。”
她眼睛一亮：“哦！那你会做网页吗？我朋友在搞区块链，需要个会React的人，你懂这个吗？”
我差点把美式喷出来——这年头连相亲对象都在拿区块链和React当筛选条件了？更要命的是，她紧接着补了一句：“你们前端不是现在都用什么CSS-in-JS吗？传统CSS是不是已经淘汰了？”
我当时脑子嗡的一声。这不是上周面试时被问到的原题吗？！
面试题挑战：从相亲桌到会议室的同款问题
没错，就在三天前，我在国贸一家号称“对标硅谷”的创业公司面试。HR给我发的岗位JD写着“熟悉现代前端工程化体系”，我以为就是Webpack + TypeScript + React那一套。结果技术面最后一轮，面试官推了推眼镜，慢悠悠地问：
“你怎么看待CSS-in-JS和传统CSS的选型？项目里怎么决策？”
我当场卡壳。不是不会答，而是这个问题太TM像“你妈和你老婆掉水里先救谁”了——两边都有道理，但说错一句就可能直接挂掉。
我支支吾吾说了几句“看场景”“团队习惯”“性能权衡”，对方点点头，没再追问。但我知道，这题我没答好。果然，当晚HR微信回我：“很遗憾，我们找到了更匹配的人选。”
那天回家，13号线挤得像沙丁鱼罐头，我站在车厢连接处，脑子里全是那个问题。房租3500、月薪15k、相亲第7次失败……当时真的有点焦虑：是不是我真的跟不上时代了？是不是CSS-in-JS才是“高级前端”的入场券？
真实战场：我在两个项目里的血泪实践
其实我早就用过这两种方案，只是没系统总结过。说出来你可能不信——我第一个正经用CSS-in-JS的项目，居然是帮前同事做的区块链钱包DApp。
那是个2021年底的外包活儿，客户要求“极致体验+快速迭代”，技术栈指定React + TypeScript。UI设计稿三天一改，动不动就要加个动画、换个主题色。传统CSS写起来简直要命——全局污染、命名冲突、样式覆盖……我一度想辞职。
后来我咬牙上了styled-components。效果立竿见影：
- 每个组件的样式完全隔离，再也不用担心
.button被全局样式污染 - 主题切换？一行代码搞定：
<ThemeProvider theme={darkTheme}> - 动态样式？直接传props：
const Button = styled.button\color: ${props => props.primary ? 'red' : 'black'};``
那个月我加班到凌晨三点是常态，但至少不用半夜爬起来修“为什么按钮突然变蓝了”这种玄学bug。
可转头到了今年年初，我又接了个政府合作项目——一个内部管理系统。需求极其稳定，UI三年不变，性能要求高，还要兼容IE11（别笑，真有）。这时候CSS-in-JS就成了累赘：
- 首屏加载慢了近400ms（实测数据），因为JS要解析、注入、执行样式
- 构建体积暴涨，Webpack bundle里光styled-components runtime就占了120KB
- 更致命的是，测试同事抱怨“没法直接用CSS选择器定位元素”，自动化脚本全崩
最后我们果断切回传统CSS + CSS Modules。每个组件一个.module.css文件，作用域隔离靠编译时哈希，性能稳如老狗。虽然改个颜色要开三个文件（JSX + CSS + Storybook），但胜在稳定、可预测、不折腾。
技术选型的本质：不是“新旧”，而是“合适”
很多人一听到“CSS-in-JS”就两眼放光，仿佛用了就能进大厂、涨工资、娶到白富美。也有人死守传统CSS，骂CSS-in-JS是“过度工程”“反人类”。
但现实哪有这么非黑即白？
上周我和现在公司的Tech Lead聊起这事，他一句话点醒我：
“工具没有好坏，只有合不合适。你是在造火箭，还是修自行车？”
如果你在做高度动态、频繁迭代、强主题定制的产品（比如SaaS后台、营销H5、DApp），CSS-in-JS能极大提升开发体验。尤其搭配React，状态驱动样式天然契合。
但如果项目性能敏感、长期维护、团队规模大（比如企业级应用、内容型网站），传统CSS（配合BEM/SMACSS规范 + CSS Modules）反而更稳、更轻、更易交接。
举个具体例子：我在相亲认识的现任老婆（对，就是开头那个问区块链的姑娘！）现在做电商运营。她们公司官网用Next.js + Tailwind CSS，静态生成、CDN缓存、首屏秒开。要是硬塞styled-components进去？SEO工程师能提刀来砍人。
关于“面试题挑战”的真相
回到那个让我失眠的面试题。后来我复盘发现，面试官根本不是要听你站队，而是考察工程思维。
好的回答应该包含：
- 场景分析：你的项目类型是什么？用户是谁？性能瓶颈在哪？
- 权衡取舍：CSS-in-JS的开发效率 vs 运行时开销；传统CSS的稳定性 vs 维护成本
- 替代方案：有没有考虑过Tailwind？Vanilla Extract？CSS-in-JS的零运行时方案（如Linaria）？
- 团队因素：新人上手成本？设计师协作流程？现有技术债？
我现在的公司（月薪22k，感谢那次失败的面试逼我成长）就在用混合策略：
- 核心产品用Emotion（支持SSR + source map调试）
- 营销落地页用纯CSS + PostCSS
- 内部工具用Tailw风
没人规定必须All in一种方案。成年人的世界，都是“既要又要还要”。
相亲教会我的技术哲学
说来好笑，最终让我理解“合适比先进更重要”的，居然是相亲。
第七次相亲失败后，我妈打电话骂我：“你非要找会React的？找个踏实过日子的不行吗？”
我嘴上犟，心里却明白：技术选型和找对象一样，不是越新越好，而是越配越好。
那个问我CSS-in-JS的姑娘，后来成了我老婆。她其实根本不懂前端，只是听她区块链圈的朋友说“这玩意儿很火”。但她愿意听我讲清楚区别，而不是盲目追捧“新技术”。
现在我们在天通苑租着3500的房子，她做运营，我写代码。周末她催我改简历跳槽，我说：“急啥，先把公司这个React重构项目做完，用啥方案我都心里有谱了。”
给正在纠结的你的建议
如果你也在为CSS方案头疼，不妨问自己几个问题：
- 你的用户会在意多出来的300ms加载时间吗？（如果是C端高频使用产品，答案很可能是“会”）
- 你的团队有专人维护CSS架构吗？（如果没有，CSS-in-JS能减少90%的样式冲突）
- 未来半年UI会大改吗？（如果会，动态样式能力值回票价）
- 你愿意为开发爽感牺牲一点运行时性能吗？（诚实回答）
别被社区KOL带节奏。2024年了，还在争论“CSS-in-JS是否邪恶”就像争论“iPhone和安卓哪个更好”——取决于你握在手里的是哪一台。
最后一点真心话
写这篇文章的时候，已经是凌晨1点。窗外天通苑的夜班车刚过，隔壁情侣又在吵架（他们上周刚分手，今天又复合了，程序员真不懂这些）。
回想自己从月薪8k到22k，从相亲被拒到领证买房（首付还是借的），最大的感悟不是“学了多少新技术”，而是学会在混沌中做判断。
CSS方案如此，人生选择亦如此。
别怕选错。选错了，大不了重构。反正我们前端，最擅长的就是——
删掉重来。
（完）
P.S. 如果你也在北京租房写代码，欢迎私信。我可以告诉你哪家天通苑的咖啡馆WiFi其实能连上（秘诀是坐靠窗第三张桌子）。
评论 0