多发一点CSS，页面反而更快：GitHub大规模样式迁移的真正方法
内容提要
GitHub将Primer设计系统从CSS-in-JS迁移到CSS Modules，服务端渲染时间减少55%，组件初始化减少25%，计划2026年6月主站实现100%迁移。关键不是选型，而是双轨兼容、量化债务、灰度回滚。团队应先定性能预算，按组件级迁移，用开关和视觉回归兜底，避免只看包体积或盲目自动改写。
延伸解读
迁移节奏：从7760到0的量化管理
GitHub的迁移并非一次性替换。2025年4月存量约7760个sx属性，8名工程师用6个月迁移6419个，不同页面服务端渲染改善1%—22%。到2026年4月，剩余895个由两名工程师与Copilot协作三周清零。这种分阶段、按组件推进的方式，让每一步都可独立回滚，避免大规模重写风险。
双轨兼容：兼容层买时间的关键设计
Primer先让组件本身使用CSS Modules，再通过@primer/styled-react包装层继续接收旧sx属性。调用方可以分包迁移，设计系统先获得部分收益，旧代码不会同时爆炸。每个组件配合视觉快照、预生产和功能开关逐步放量，迁移变成一系列可逆的小变更，而非一次性切换。
指标陷阱：别只看包体积和跨页面比较
评估迁移效果时，只看JavaScript包体积会忽略浏览器解析CSS、缓存命中和首屏关键样式。同时，把实验组与不同页面、不同流量时段直接比较也不可靠。更稳妥的做法是在同一页面、同一主题和近似设备条件下做灰度，观察服务端渲染、最大内容绘制、交互延迟、样式计算和错误率，并按高分位数判断。
自动化边界：Codemod的停止线与人工兜底
自动改写只适合机械转换。遇到条件表达式、动态token、伪类组合或主题分支时，Codemod应生成待办而非猜测CSS。每个转换提交保留旧路径开关和视觉差异图，确认无回归后再合并下一批。主题系统往往是最后一公里，CSS变量不能直接用于媒体查询，一些sx值并非一对一映射，编译通过不等于视觉语义不变。
Q&A
GitHub 把样式从 CSS-in-JS 迁移到 CSS Modules 后，性能提升了多少？
GitHub 官方测得页面服务端渲染时间减少 55%，页面组件初始化时间减少 25%。
为什么说“多发一点 CSS”反而可能让页面更快？
因为 CSS-in-JS 会在运行时把样式对象转换成规则、生成类名、收集服务端样式并处理更新，带来客户端与服务端的运行时成本；而 CSS Modules 在构建期就把局部类名编译进静态样式表，浏览器能按擅长的路径解析和缓存，JavaScript 少做工作，即使传输的 CSS 稍多，总交互成本仍可能下降。
GitHub 的样式迁移是如何做到不影响现有代码的？
Primer 设计系统先让组件本身使用 CSS Modules，同时通过 @primer/styled-react 包装层继续接收旧 sx 属性，实现双轨兼容。调用方可以分包迁移，旧代码不会同时爆炸，每个组件配合视觉快照、预生产和功能开关逐步放量，迁移变成一系列可逆的小变更。
普通团队在样式迁移时最应该先做什么？
先定义性能预算，不要把“移除某库”当目标，至少观察服务端渲染、交互启动、样式更新、CSS 与 JavaScript 传输量；然后把迁移单位控制在组件或包级，确保每一步能独立回滚；自动改写只负责机械转换，响应式规则、主题变量和可访问性状态必须由视觉回归与人工审查兜底。
样式迁移中主题系统为什么是难点？
GitHub 支持七种主题及高对比变体，移除 styled-components 前还要把 JavaScript 主题工具解耦为 CSS 变量。Primer 文档提醒，CSS 变量不能直接出现在媒体或容器查询表达式中，一些 sx 值并非一对一映射，编译通过不等于视觉语义保持不变。
哪些团队可能不适合做这种样式迁移？
如果样式高度依赖每帧动态数据，或者团队规模很小、运行时开销未进入性能剖析前列，迁移成本可能大于收益。高组件密度、服务端渲染明显、主题稳定的产品最可能受益。
评估样式迁移效果时，要避免哪些指标比较陷阱？
要避免两个陷阱：一是只看 JavaScript 包体积，却忽略浏览器解析 CSS、缓存命中和首屏关键样式；二是把实验组与不同页面、不同流量时段直接比较。更稳妥的做法是在同一页面、同一主题和近似设备条件下做灰度，分别观察服务端渲染、最大内容绘制、交互延迟、样式计算和错误率，再按高分位数判断。
自动化改写工具在样式迁移中应该怎么用？
自动改写只负责机械转换，遇到条件表达式、动态 token、伪类组合或主题分支时，Codemod 可以生成待办而不是猜一个 CSS。每个转换提交保留旧路径开关和视觉差异图，确认无回归后再合并下一批。这样做看似慢，却能避免把几千个机械变更堆成一个无人敢审的超大 PR。
