从CSS-in-JS踩坑到回归原生：一个外包仔的样式方案血泪史

上周五晚上十点半，我戴着 AirPods 单曲循环 Billie Eilish 的《Bury a Friend》，盯着屏幕上一团糟的样式冲突，差点把 MacBook 合上直接躺平。这已经是这个月第三次因为 styled-components 的动态 props 导致组件渲染性能翻车了——而明天就是客户验收 deadline。

我是北京某“灵活就业”程序员，主业在一家中型 SaaS 公司写 React 前端，副业接些区块链相关的外包项目（别问，问就是 Web3 热潮退去后遗留的维护单子）。每天通勤一小时挤地铁时，脑子里不是想着怎么优化 bundle size，就是在盘算下个月房租能不能靠副业 cover 掉。代码质量？架构设计？当然在乎！但前提是活儿得先交出去。

今天这篇不是教科书式的对比评测，而是我在多个 React 项目里反复横跳 CSS 方案后的真实开发心得。尤其最近那个 NFT 钱包前端重构项目，让我彻底重新审视了“现代前端样式到底该怎么写”。

起因：一个看似简单的 UI 重构需求

事情要从去年底说起。一个做数字藏品交易平台的客户找我重做他们的钱包连接页。UI 设计稿看起来人畜无害：深色主题、圆角卡片、hover 动画、响应式布局——典型的现代感界面。我心想：“小菜一碟，用我熟悉的 styled-components + themeProvider 搞定。”

结果第一天就翻车了。

他们要求支持 动态切换主题（白/黑/蓝三色），且必须和链上用户偏好同步（是的，有些链上合约居然存了主题色，真·区块链赋能 UI 🙄）。更坑的是，页面里嵌了一个第三方 SDK 的 iframe，而我们的全局样式竟然污染了人家的按钮！

当时我就意识到：传统 CSS 的全局作用域问题还在，而 CSS-in-JS 的运行时开销可能比我想的严重得多。

第一回合：CSS-in-JS 的甜蜜陷阱

先说说我为啥一开始偏爱 CSS-in-JS。作为斜杠程序员，我最怕的就是上下文切换。在 .js 文件里直接写样式，不用切到 .css 文件，还能用 JS 变量、函数、逻辑判断——对赶工期的外包党来说简直是神器。

比如下面这段代码，在副业项目里很常见：

// WalletButton.jsx
import styled from 'styled-components';

const WalletButton = styled.button`
  background: ${props => props.connected ? '#00ff88' : '#333'};
  border-radius: 12px;
  padding: 12px 24px;
  color: white;
  font-weight: 600;
  transition: all 0.2s ease;
  
  &:hover {
    transform: ${props => props.disabled ? 'none' : 'scale(1.05)'};
  }
`;

看起来多优雅！状态驱动样式，逻辑内聚。而且配合 VS Code 的 styled-components 插件，语法高亮、自动补全一应俱全。

但问题很快就来了：

1. Bundle Size 膨胀：引入 styled-components 本身就要 15KB+（gzip 后），而我的副业项目往往追求极致轻量。
2. SSR 渲染水合（hydration）出错：有一次本地开发好好的，上线后 SSR 渲染的 HTML 和客户端 JS 水合不一致，导致整个页面闪一下白屏。查了半天才发现是动态 class 名生成顺序不一致。
3. 调试困难：Chrome DevTools 里看到的是一堆 sc-xxxxx 的类名，想直接改样式调试？没门。虽然有 Babel 插件可以保留组件名，但配置起来又是一堆麻烦事。

最致命的是性能。在那个 NFT 项目里，钱包地址列表有上百个卡片，每个卡片都用 styled-components 写了 hover 效果。结果一 hover，FPS 直接掉到 30 以下。用 Performance 面板一抓，发现大量时间花在 insertRule 和 style 计算上。

💡 真实场景：测试妹子提了个 bug：“鼠标划过资产列表卡顿”。我当时第一反应是：“是不是图片太大？” 结果一看 network，图片都加载完了。最后 profiling 才发现是样式系统背锅。

第二回合：重回原生 CSS，但这次带上了现代化装备

被 CSS-in-JS 折磨一周后，我决定试试“传统”方案——但不是回到刀耕火种时代。现在都 2024 年了，原生 CSS 早就不是你爷爷辈的 CSS 了。

我选了 CSS Modules + PostCSS + :has() 伪类 的组合拳。

CSS Modules：告别全局污染

首先，.module.css 文件天然解决作用域问题。每个类名都会被哈希化，再也不用担心“不小心覆盖了 antd 的 button 样式”这种社死现场。

/* WalletButton.module.css */
.btn {
  border-radius: 12px;
  padding: 12px 24px;
  font-weight: 600;
  transition: all 0.2s ease;
}

.connected {
  background: #00ff88;
  color: black;
}

.disabled {
  opacity: 0.6;
  cursor: not-allowed;
}

.btn:hover:not(.disabled) {
  transform: scale(1.05);
}

// WalletButton.jsx
import styles from './WalletButton.module.css';

export default function WalletButton({ connected, disabled }) {
  return (
    <button 
      className={`
        ${styles.btn} 
        ${connected ? styles.connected : ''} 
        ${disabled ? styles.disabled : ''}
      `}
    >
      Connect Wallet
    </button>
  );
}

虽然要多写几行 className 拼接，但换来的是：

• 零运行时开销（样式编译时确定）
• DevTools 里直接看到语义化类名（如 WalletButton_btn__abc123）
• 更容易做静态分析和 tree-shaking

PostCSS + 新特性：让 CSS 也能“编程”

你以为原生 CSS 就不能写逻辑？PostCSS 插件生态早就能让你写出接近 Sass 的体验，还不用引入额外语言。

比如用 postcss-nested 支持嵌套：

.btn {
  /* ... */
  &:hover {
    /* ... */
  }
}

再比如用 postcss-custom-media 定义响应式断点：

@custom-media --mobile (width <= 768px);

.card {
  @media (--mobile) {
    padding: 8px;
  }
}

甚至，借助现代浏览器支持的 CSS 自定义属性（CSS Variables），我们完全可以实现主题切换，而且比 JS 动态注入高效得多：

:root {
  --primary: #333;
  --success: #00ff88;
}

[data-theme="dark"] {
  --primary: #eee;
  --success: #00cc66;
}

.btn {
  background: var(--primary);
}

JS 只需一行切换：

document.documentElement.setAttribute('data-theme', userThemeFromChain);

零重渲染！纯 CSS 层切换！这对性能敏感的钱包界面来说太重要了。

:has() 伪类：父选择器的救星

以前最头疼的就是“根据子元素状态改变父元素样式”，比如“当输入框有错误时，高亮整个表单组”。传统做法要么用 JS 打标记，要么用兄弟选择器绕弯子。

现在有了 :has()，直接：

.form-group:has(.input.error) {
  border-color: red;
  box-shadow: 0 0 0 2px rgba(255, 0, 0, 0.2);
}

虽然目前 Safari 支持稍晚（iOS 15.4+），但考虑到我们的用户大多是桌面端 Chrome/Firefox，完全可用。

✅ 实测数据：在钱包资产列表页，使用 CSS Modules + CSS Variables 后，hover 交互 FPS 从 28 提升到 58，bundle size 减少 18KB。

对比表格：别光听我说，看数据

维度	CSS-in-JS (styled-components)	原生 CSS (Modules + PostCSS)
Bundle Size	+15KB~20KB (runtime)	0 额外开销
运行时性能	中低（动态插入规则）	高（静态样式）
主题切换	需重渲染组件	纯 CSS，无需 JS 介入
调试体验	类名混淆，需插件	语义化类名，DevTools 友好
浏览器兼容	依赖 JS，老旧浏览器需 polyfill	原生支持，可控降级
学习成本	需学特定 API	标准 CSS + 少量工具链
与第三方库集成	容易冲突（如 iframe）	作用域隔离，安全

特别提醒：如果你的项目重度依赖 服务端渲染（SSR） 或 静态站点生成（SSG），CSS-in-JS 的水合问题会非常头疼。而原生 CSS 在构建时就能提取为独立文件，SSR 输出干净 HTML，毫无压力。

区块链项目的特殊考量

说到区块链，很多人觉得就是炒概念。但在我接的这些外包单子里，确实有些真实的技术约束：

1. 极致轻量化：DApp 用户往往网络环境差（尤其海外），bundle 能小 1KB 是 1KB。
2. 安全隔离：钱包页面常嵌入第三方 SDK（如 MetaMask、WalletConnect），样式污染可能导致安全漏洞（比如伪装成“确认”按钮）。
3. 离线可用：部分 DApp 要求离线也能展示基础 UI，原生 CSS 缓存策略更简单可靠。

CSS-in-JS 的运行时在这类场景反而是累赘。反观原生 CSS，配合 <link rel="preload"> 和 HTTP/2，首屏加载快得飞起。

我现在的选择策略

经过这几个项目的折腾，我总结了一套“务实主义”选型指南：

• 小型项目 / 快速原型：用 CSS Modules + PostCSS。够用、轻量、无脑。
• 需要复杂动态样式（如数据可视化）：局部用 CSS-in-JS，比如 emotion 的 css prop，避免全局引入 runtime。
• 团队强推 Design System：如果公司已有成熟的 styled-components 主题体系，那就跟着走，别造轮子（除非你不怕被 PM 吵）。
• 性能敏感型应用（如交易界面、游戏）：坚决不用 CSS-in-JS，连 Tailwind 都要谨慎评估。

顺便吐槽一句：有些大厂面试官还喜欢问“你为什么选 styled-components”，搞得好像不用就 out 了似的。其实技术没有银弹，只有合适不合适。

最后几句真心话

作为靠代码吃饭的斜杠青年，我越来越觉得：工具越简单，活得越久。

CSS-in-JS 当年火起来，是因为它解决了“组件化样式”的痛点。但现在，原生 CSS 通过 Modules、Variables、Container Queries、:has() 等特性，已经能覆盖 90% 的场景，而且更稳定、更高效。

上周我把那个 NFT 项目的样式全迁移到 CSS Modules，不仅性能达标，客户还夸“页面加载快多了”。最重要的是——我不用再半夜被报警电话叫醒，因为“用户说按钮颜色突然变紫了”。

通勤地铁上，我听着新歌，心里盘算着：下个月房租有着落了，今晚要不要加个鸡腿？

---

开发心得总结：

1. 别为了“现代化”而现代化，性能和可维护性才是王道。
2. 在 React 项目里，样式方案的选择直接影响用户体验，尤其是交互密集型页面。
3. 区块链相关前端更要注重轻量与安全，花哨的方案未必适合。
4. 外包项目周期短，工具链越简单，交付越稳。

共勉。