GitHub 复盘 CSS Modules 迁移：性能改进来自渐进替换与持续验证
GitHub于2026年9月25日发布工程复盘，介绍github.com从CSS-in-JS迁移到CSS Modules的过程。文章说明整体迁移在2026年6月完成，因此这是近期公开的经验总结，不是9月刚上线的新功能。团队采用组件级开关、视觉回归与逐步放量，并通过过渡包装层兼容尚未迁移的用法。官方复盘。
图：AI生成样式架构渐进迁移概念配图，非产品界面或性能实测图。
不要把一个站点的收益直接写进自己的指标
官方描述了不同阶段的服务端渲染与初始化改善，也强调最后仍需处理主题体系和依赖移除。收益来自特定架构与规模，无法据此推断任何项目换成同一种方案都会同样变快。值得借鉴的是如何确认成本、逐步替换并验证没有破坏既有体验。
独立分析：从有证据的瓶颈开始
如果团队考虑类似迁移，可先选一个组件较密集、访问量有代表性的页面，记录服务端处理、客户端初始化和用户可交互时间。固定数据规模与测试设备，检查样式生成是否确实占了值得优化的部分。若主要耗时来自接口等待或图片资源，优先改样式架构未必划算。
然后选一个边界明确的组件做试验，保持对外接口尽量稳定。比较新旧实现的布局、交互、焦点状态、禁用状态和不同主题，尤其检查长文本、窄屏与高对比度下的表现。静态截图一致很有帮助，但不能代替键盘操作和动态状态验证。
兼容层要有退出条件
渐进迁移通常需要一段新旧并存的时期。建议在开始时就记录旧用法的数量、允许继续使用的范围，以及何时停止新增。否则兼容层可能永久存在：新方案已经上线，旧运行时却仍被大量路径引用，团队承担两套方案的维护成本，又很难确定实际收益。
每次放量都保留回退路径，并分别记录视觉缺陷、功能缺陷和性能变化。若某个页面变慢，先分析资源拆分和加载方式，而不是直接把原因归结为新技术“不适合”。不同页面可能需要不同粒度的调整，迁移也不必为了统一而忽略事实。
这篇复盘对小团队最实用的启发，是把架构迁移变成可测量的小步骤：先证明值得做，再证明每一步没有破坏体验，最后才移除旧依赖。选择技术方案只是起点，能够持续验证与安全退出，才让长期改造成为可控的日常工程。
核对时间：2026年10月1日（北京时间）。发布事实依据所链接的一手资料，实践建议为本站独立分析；测试状态、可用范围与文档可能继续更新。
