现代软件基础设施的臃肿与衰退：以 GitHub 为例
现代软件开发生命周期几乎与 GitHub 划等号。对于许多开发者来说，它是托管代码和进行协作的默认方式——有时甚至是唯一的方式。然而，随着该平台在 Microsoft 的所有权下不断壮大，一种令人不安的基础设施衰退模式已经显现。曾经作为程序员的高性能工具，如今正日益成为“大厂”软件腐烂的象征：其特征是可靠性问题、激进的 AI 集成以及惊人的前端臃肿。
这不仅仅是偶尔停机的问题。这是一种软件架构的系统性失败，即华丽的功能被置于系统最基本的稳定性和效率之上。通过分析该平台的实际性能指标并将其与替代方案进行比较，我们可以看到一条清晰的衰退轨迹，这反映了整个行业更广泛的趋势。
可用性的幻象
GitHub 的官方状态页面经常声称高可用性（约 99.8%），但用户的实际体验却经常与之矛盾。第三方监控工具经常揭示出低得多的现实，这表明官方指标可能具有误导性。
当可靠性问题出现时，企业的回应通常将“代理开发工作流”（agentic development workflows）——即 AI 驱动自动化的激增——视为系统压力的主要驱动因素。然而，这是一个循环问题。Microsoft 和 GitHub 已经激进地将 Copilot 和其他 AI 代理推向 UI 的每一个角落，通常还通过补贴其使用来推动采用。通过鼓励其自身基础设施上自动负载的大幅增加，他们实际上是在对自己进行分布式拒绝服务（DDoS）攻击。
优先级差距：AI vs. 可靠性
企业辞令与实际开发优先级之间存在着显著的脱节。虽然 Microsoft 声称可用性和容量优先于新功能，但公开的变更日志（changelog）却讲述了不同的故事。在最近的一个 30 天窗口期内，“Copilot”一词在补丁说明中出现了 59 次，而“performance”和“reliability”一次都没有出现。
这种优先级排序在用户界面中清晰可见。一个典型的仓库落地页现在拥有多个专门用于启动 AI 代理的按钮，这些按钮往往挤占了页面的主要功能元素。这表明了一种文化，即“华丽”的 AI 路线图优先于维护稳定、高性能后端所做的“隐形”工作。
量化臃肿程度：技术对比
为了理解衰退的程度，观察前端代码——即交付到每个用户浏览器中的系统部分——是非常有用的。一项对比 GitHub、GitLab 和 Codeberg（使用一个极简仓库）的受控实验揭示了资源使用量上的惊人差异。
内存与网络开销
即使对于一个空白仓库，资源需求也令人咋舌：
- GitHub: 通过近 300 个文件拉取了大约 15 MiB 的数据。展开的代码由超过 500,000 行 JavaScript 和 CSS 组成。
- GitLab: 通过 70-120 个文件拉取了大约 7-8 MiB 的数据，包含大约 100,000 行代码。
- Codeberg: 通过 11 个文件拉取了大约 1 MiB 的数据，仅包含约 1,100 行代码。
在 RAM 使用方面，GitHub 和 GitLab 即使在空闲状态下也表现出显著的“稳态”堆内存（heap）使用（约 68-69 MiB）。在包含实际内容的页面上，例如大型 pull request 列表，GitHub 的堆内存使用量可能会飙升至超过 148 MiB——对于一个以文本为主的页面来说，这是不可原谅的内存占用。
性能成本
达到可用状态（完全加载）的时间差异巨大。在受限的“Fast 3G”条件下，GitHub 可能需要超过 20 秒才能完全加载一个空白页面。即使在高速光纤连接下，由于大量独立的、针对微小 JavaScript 分片的 HTTP 请求（这是激进的 Webpack splitting 的副产品）产生的开销，也会造成明显的延迟。
超越“腐烂化”（Enshittification）
“Enshittification”一词通常描述一种产品在损害用户利益的同时为了公司利益而退化。但 GitHub 的衰退感却不同。让代码库如此臃肿以至于增加服务器成本并需要数百万工程师小时来维护，这并没有明显的业务优势。
相反，这似乎是技术领导力的失败。当一个平台变得“大到不能倒”时，维持精简、高效代码的动力就会消失，取而代之的是“功能发布”和 LLM 生成的代码垃圾。其结果是一个功能上类似于“肥胖的赛马”——能够奔跑，但效率极低。
社区视角与替代方案
开发者社区的反应是分裂的。一些用户仍然感到满意，由于集成的生态系统（Actions, Copilot, Issues）的价值超过了性能成本，他们认为这是值得的。然而，其他人则日益转向自托管或更轻量级的替代方案。
"I've been an avid GitHub user for a very long time... But times are a-changin'... I put that puppy on my tailnet, installed Gitea, and I've been using it exclusively for all my projects. I feel free."
此外，关于通过社会资本实现的“锁定”也存在日益增长的担忧。正如一位评论者所言，真正的锁定并非仅仅是代码，而是“GitHub stars”—一个衡量项目重要性的货币，这种货币可以被操化纵或购买，从而使平台进一步远离其基于功绩主义的开源协作的初衷。
结论
软件的初衷是高效地解决问题。当我们用来构建软件的工具本身成为了低效的主要来源时，这便是一个信号，预示着工程诚信的度的危机。一个小型志愿者团队所能实现的成就（如 Codeberg 所见）与一家万亿美元规模的公司所产出的物产之间的差距，是对当前大厂软件开发现状的毁灭性控诉。如果行业继续优先考虑 AI 驱动的增长而非基础的稳定性，我们就有可能将整个数字基础设施构建在摇摇欲坠、臃肿且垃圾般的基石之上。