当前位置：首页 > news >正文

GitHub问题频发：可靠性堪忧，前端代码臃肿，与竞品对比差距明显！

news 2026/6/3 4:14:16

引言

作者开始写文章时，GitHub又宕机了。尽管已有很多文章讨论过GitHub在可靠性、安全性和性能方面的问题，但这些都只是触及了表面。GitHub就像是一种“信号”，反映了GitHub自身以及整个大型科技软件服务领域的基础设施衰退问题。虽然几乎每个大型科技公司的服务都存在类似的衰退问题，但GitHub尤为突出，因为它几乎成了软件开发的代名词。

GitHub近期问题的小样本

根据GitHub自己的公开通报，每月会发生数十起事故，这意味着实际事故率可能高达数百起。GitHub不公开Bug列表或问题页面，将问题深藏在邮件链中。GitHub不断向用户谎报其正常运行时间和优先级，即使按照其自身指标，它也违反了服务水平协议。而且，GitHub显然更注重花哨的AI功能，而非基础的可靠性。

GitHub上“智能代理”负载的增加，直接源于其自身及其母公司微软的行为，这使得可靠性问题完全是它们自己的过错。GitHub在Firefox和Safari等拥有数百万用户的浏览器上经常出现故障。GitHub容忍其服务上明显的“买粉丝”和“买星”行为，并推广明显是刷量的仓库。

GitHub的拉取请求页面运行迟缓，且极其耗费内存。GitHub经常重置或更改项目和用户设置，新功能默认开启，即使这些功能存在极大风险。GitHub显然更重视花哨的“AI”项目，而非真正付费的客户。

GitHub Actions设计糟糕、运行缓慢且文档不完善，很可能是“用YAML编写的shell脚本”式构建系统中最糟糕的。GitHub Actions的日志会泄漏内存，多年来多次导致浏览器崩溃，而且至今仍无法将标准输出重定向到其他地方。GitHub“默认”操作的默认缓存行为极其幼稚，甚至比没有缓存还糟糕；很多操作根本不进行缓存失效处理。

GitHub的前端臃肿且运行缓慢，十分可笑，经常在Safari和Firefox上出现故障，还不断在没有警告或解释的情况下更改用户体验，常常故意用更多指向其“AI”系统的引导，取代原本有用的UX部分。

GitHub不断向用户谎报其正常运行时间和优先级

GitHub的官方状态页面声称其正常运行时间约为99.8%，但实际数字连一个9都没有。GitHub很清楚自己最近陷入了困境，于是发布了一些新闻稿来试图转移批评。

微软称主要驱动因素是软件开发方式的快速变化，智能代理开发工作流程急剧加速。但使用被动语态说“智能代理开发工作流程急剧加速”很荒谬，因为GitHub归微软所有，微软以各种重叠的方式将AI、“智能代理”等融入了每一款产品。

GitHub和微软一直在各种情况下推动用户使用“AI”和“智能代理”。很难夸大他们希望用户使用这些东西的程度，在普通仓库主页的右上角四分之一区域内，就有四种不同的方式可以启动Copilot。

多年来，GitHub为了推动这些工具的使用，对使用成本进行了补贴，实际上是在对自己进行分布式拒绝服务攻击。微软称优先级是可用性、容量和新功能，但GitHub显然更注重花哨的AI功能，而非基础的可靠性。

同样由微软拥有的Visual Studio Code直接集成了GitHub及其“智能代理”功能，而且在基本功能逐渐变得几乎无法使用的情况下，仍不断添加更多功能。

微软承认系统设计存在问题，性能是软件架构的下游产物。GitHub可靠性问题的根源在于其后端和数据库，不过可以查看其前端代码来了解其技术能力。

GitHub的前端代码一团糟：GitHub、GitLab和Codeberg的比较

图片：GitHub、GitLab和Codeberg的仓库主页

GitHub及其竞争对手的大多数前端页面，本质上是带有一些简单用户体验元素和搜索栏的链接列表。这些服务的页面在功能和外观上基本相同，Codeberg和GitLab都有意模仿了GitHub的用户体验。

实验设计

为了确定这些前端的成本并估算潜在的bug数量，设计了一个实验。尽量减少干扰变量，将网络速度限制为“快速3G”连接，使用相同的最小化仓库进行比较，所有实验都使用相同的浏览器和计算机，研究每个服务的四个页面。

实验步骤

创建一个名为“ghsucks”的最小化Git仓库，将该Git仓库上传到每个远程仓库。对于每个页面，清空缓存后收集HTTP存档网络请求、页面加载完成后收集堆内存快照、使用“testcompress”收集压缩支持信息。分析数据，使用“anhar”分析HAR，使用“testcompress”分析压缩支持情况。使用第三方服务对这些网站进行分析。