我们全面迁移github.com，摆脱CSS-in-JS。2026年9月25日 | 8分钟分享：Primer设计系统驱动着您今天在GitHub上看到的许多体验。从按钮到横幅，再到面包屑，这些基础组件必须在各种场景中保持可访问性、灵活性和性能。回到2023年，某些页面上的组件数量开始激增。这导致我们现有的CSS-in-JS解决方案面临几项与性能相关的挑战：初始页面加载时间因样式在客户端初始化而变长；服务器端渲染性能下降，因为样式收集从客户端转移；页面上组件数量的增长导致样式更新失控。显然，Primer团队需要从根源解决这个问题。我们需要找到一个替代方案，完全避免我们在当前解决方案中遇到的客户端和服务器成本。最重要的是，任何我们选择的替代方案都需要以一种避免在迁移过程中对GitHub造成破坏的方式运行。引入CSS（模块）Primer团队找到了一种满足我们所有标准的解决方案：CSS模块。这种格式将允许我们做我们最喜欢的事情之一：编写和使用原生CSS特性，同时仍允许我们期待从CSS-in-JS中获得的某种程度的共同定位和封装。使用CSS模块时，样式将在CSS文件中进行编写，与组件的JavaScript源代码并排。它还将允许我们默认将所有类名视为局部的，从而防止一些全球选择器可能带来的冲突和挑战。这种格式还消除了任何客户端或服务器运行时行为的需要。相反，样式会汇聚成CSS样式表，作为页面HTML的一部分发送。然而，这一解决方案与我们当时的CSS-in-JS解决方案截然不同。这个变化将要求对每一个Primer组件和每一个使用这种技术在GitHub上编写的组件进行更新。幸运的是，设计系统是一个完美的载体，可以在大规模上交付这种变化。向CSS模块逐步迈进，向CSS模块转变的情况十分明确。Primer团队需要为每个组件提供更新，将它们从CSS-in-JS迁移到CSS模块。与此同时，我们对这些组件所做的更新不能破坏GitHub中的任何使用。最后，我们用于CSS-in-JS的底层技术也必须继续为GitHub中当前使用它的任何组件工作。在所有这些约束下，我们决定采取逐步迁移策略，以便在不破坏现有功能的情况下安全地发布组件更新。对于每个组件，我们的计划是：添加一个新文件，将现有样式转换为CSS模块；将组件添加到一个功能标志，该标志将在新旧样式之间切换；使用现有的视觉回归测试来验证我们的CSS-in-JS解决方案和CSS模块之间的快照是相同的；逐步将功能标志推出给我们的团队，然后向GitHub员工，最后向所有GitHub用户，以便在此过程中捕捉任何问题。这个过程创造了一个强大的反馈循环，在Primer不断将这些更改交付给GitHub的过程中，问题被及早标记。使用功能标志使我们能够安全地进行这种迁移，同时为我们提供了关于CSS模块性能收益的清晰信号。到2024年12月，所有Primer组件都通过此流程迁移到CSS模块。我们看到了整体性能上的提升，特别是：服务器端渲染页面的时间减少55%；页面上组件初始化的时间减少25%。通过在Primer中进行这些工作的明显性能收益，我们开始想知道是否可以在GitHub的其他部分中看到类似的性能提升。同样，我们还需要多长时间才能最终完全停止对CSS-in-JS的支持？从GitHub中移除CSS-in-JS，去除Primer中CSS-in-JS解决方案中最棘手的部分之一是sx属性的使用。这个属性是用于样式和定制Primer组件的方式。团队可以提供一个内联对象来定制组件的各个方面。它代表了CSS-in-JS的最佳和最差部分：与我们的设计令牌集成的优秀TypeScript支持；与组件同处一地，因此一切都在一个地方；由于用于sx的动态内联对象的性质，运行时成本高；随着页面上使用sx的组件数量的增加，扩展困难。因此，我们迈出离开CSS-in-JS的第一步是减少GitHub上的sx使用。这将使我们能够立即改善性能，类似于我们在迁移Primer组件时所看到的收益。它也为我们完全去除产品中的CSS-in-JS做好了准备。Primer的双重性。重要的是要注意，尽管设计...