裁员后接外包，我在样式方案上踩过的那些坑

去年十月被裁后，我开始一个人接外包。没有架构师拍板，没有同事拆任务，每个技术选型的代价都直接变成我的睡眠。这一年多我在 CSS-in-JS 和传统 CSS 之间反复横跳，踩了不少坑，写下来做个复盘。

第一个项目：styled-components 的教训

被裁后接的第一个外包是电商后台，预算 3 万 5，React + Ant Design。我图省事直接上了 styled-components，前两周确实爽：

const StyledCard = styled.div`
  background: #fff;
  border-radius: 8px;
  box-shadow: 0 2px 8px rgba(0, 0, 0, 0.08);
  transition: all 0.3s ease;

  &:hover {
    box-shadow: 0 4px 16px rgba(0, 0, 0, 0.12);
  }

  .ant-card-body {
    padding: 16px 20px;
  }
`;

第三周客户要求加“皮肤切换”功能。我的主题色硬编码在几十个组件的模板字符串里，全局搜索替换根本搞不定。最后硬着头皮用 CSS 变量 + ThemeProvider 重构，加班到凌晨三点。那一刻我意识到：选错方案的代价就是自己的睡眠。

第二个项目：传统 CSS 的反击

第二个外包是内容展示站，预算 1 万 8，要求 SEO 友好、加载快。我回到 CSS Modules + PostCSS：

/* Card.module.css */
.card {
  background: var(--bg-card);
  border-radius: 8px;
  transition: box-shadow 0.3s ease;
}

.card:hover {
  box-shadow: var(--shadow-hover);
}

.cardBody {
  padding: 16px 20px;
}

这个项目交付很快，但传统 CSS 也有坑。类名管理烦琐，isActive、isDisabled、hasError 条件拼接起来像写正则。更实际的问题是：样式和逻辑分离造成心智负担，写组件时要在 .jsx 和 .module.css 之间来回切换，状态多了经常忘了类名定义在哪。

外包项目的现实约束

接外包和在公司做项目最大的区别是：方案必须考虑维护成本和交付速度的平衡。客户不关心技术，只关心能不能按时交付、会不会出问题、改起来贵不贵。

有次接了个 AI 工作流展示页，预算 8000，纯静态展示。交付前三天客户突然要加暗色模式。手写 CSS 加暗色模式意味着给每个颜色定义两套变量，再写大量 [data-theme="dark"] 覆盖规则。最后花了一个通宵用 CSS 变量重构。

教训是：选型之前必须预判需求的变动方向。外包客户的需求变动比公司内部更随意，因为决策链条短，老板拍脑袋就能改需求。你没法用“技术规范”约束他们，只能让自己的代码尽量灵活。

和 GitHub Copilot 的翻车经历

Copilot 写业务逻辑能提速，但写样式经常挖坑。有次它自动补全了一段表格样式：

const TableWrapper = styled.div`
  .ant-table {
    font-size: 13px;

    .ant-table-thead > tr > th {
      background: #fafafa;
      font-weight: 600;
    }
  }
`;

上线后客户反馈部分页面表头背景色不对。查了半天，是 Copilot 生成的嵌套选择器权重太高，覆盖了 Ant Design 某些状态下的默认样式，还和另一个组件产生了交叉影响。

教训是：AI 生成的样式代码，必须逐行 review 选择器权重和嵌套层级。Copilot 不懂你的全局样式架构，只会生成“看起来对”的代码。样式这种东西，差之毫厘谬以千里。

CrewAI 项目里的混合方案翻车

今年年中给一个 AI Agent 团队做监控面板，数据更新频率高，界面元素多。我尝试了混合方案：全局布局用 CSS Modules，业务组件用 CSS-in-JS。结果问题比收益多。

首先是构建配置复杂，要同时配置两套 Babel 插件和 Webpack loader。其次是样式优先级问题：CSS-in-JS 默认注入到 <head> 末尾，而 CSS Modules 通过 link 标签引入，选择器权重相同时 CSS-in-JS 会赢，导致“明明改了 CSS Modules 里的样式为什么不生效”的诡异情况。

最后我收敛了方案：统一用 CSS-in-JS，因为动态样式需求确实多。代价是首屏多了约 20KB 运行时，但客户对性能不敏感，更在意开发速度和动态能力。

我的选型底线

踩了这么多坑，我现在接外包的样式选型有四个判断标准：

第一，看项目生命周期。 一次性交付、后续少维护的展示型项目，传统 CSS 或 CSS Modules 足够。长期迭代、需要主题切换和动态样式的，CSS-in-JS 的灵活性值得那点性能开销。

第二，看团队协作模式。 就我一个人写，怎么顺手怎么来。有客户方开发参与或以后要交接，传统 CSS 学习成本更低、交接更友好。

第三，看性能要求。 CSS-in-JS 的运行时开销是真实存在的。C 端页面、移动端 H5、需要极致首屏速度的场景，用传统 CSS 或编译期方案（linaria、vanilla-extract）。B 端后台无所谓。

第四，预判需求变动方向。 客户会不会突然要暗色模式？会不会要主题定制？如果答案是“很可能”，CSS-in-JS 的 ThemeProvider 体系能省很多事。

写在最后

被裁之后最大的变化不是技术上的，而是心态上的。以前技术选型可以开会讨论半天，现在每一个决定都直接和收入挂钩。选错了方案，代价就是熬夜返工、延迟交付、尾款被扣。

样式方案没有银弹。CSS-in-JS 和传统 CSS 各有各的好，也各有各的坑。真正重要的是：动手之前想清楚项目的真实需求，而不是被技术潮流带着走。

客户根本不在乎你用不用 CSS-in-JS，他在乎的是页面好不好看、加载快不快、改起来方不方便。技术是为人服务的，不是反过来。这个道理，我是被裁之后才真正想明白的。