过去十多年时间里，GitHub 几乎等同于「代码的互联网」和「开发者的 Facebook」。找项目、提 Issue、交 PR、看别人怎么写和怎么协作，只要打开 GitHub，基本就能完成。如果一个项目不在 GitHub 上，很多开发者会本能地觉得这个项目压根就没人开发过，完全不存在。也正因为如此，当这个平台开始频繁掉链子、收费策略又变得复杂时，引发的信任危机也足以引发整个行业的重视。

从代码仓库到开发者的精神家园

GitHub 出生在 2008 年，技术栈是当时红极一时的 Ruby on Rails，用来托管基于 Git 的代码仓库。Git 本身是 Linus Torvalds 为管理 Linux 内核在 2005 年写的分布式版本控制系统，功能非常强大，但使用体验也非常不友好。

图源：网络

基于这个痛点，GitHub 给 Git 包上了一层漂亮的 Web UI，加上用户主页、关注、Star 等类社交功能，把代码托管平台做成了「开发者的 Facebook」。

随着用户和项目指数级增长，GitHub 早已不只是一个放代码的地方。对开源来说，它几乎是事实上的公共档案馆；对企业来说，它是团队协作、代码审查、流水线自动化的中心节点；对个人来说，它是履历、作品集和学习资源库。

慢慢地，「如果一个项目不在 GitHub 上，感觉就不太正规」，成了不少人半开玩笑却又是事实的评价。

图源：网络

2018 年，微软以约 75 亿美元收购 GitHub，将其纳入自己的云与开发者生态中。毕竟微软收购诺基亚、收购 Bungie 这样的失败案例就在眼前，这笔交易在当时也引发了大量担忧，担心这家老牌大厂又会像以往的收购一样，把 GitHub 也搞砸。

有趣的是，收购后 GitHub 与微软反而进入了蜜月期。GitHub Actions 把持续集成和交付直接嵌入平台；Codespaces 尝试用云端开发环境简化配置；安全、代码扫描之类的功能也陆续上线。很多原本怀疑微软的人，也不得不承认，至少在那个阶段，GitHub 并没有被毁掉，反而越发巩固了自己在行业中的基础设施地位。

这样的行业地位也带来了一种被放大的依赖，很多团队的工作流已经深深绑在 GitHub 上，只要其中任何一个环节出现问题，就会让团队的所有工作发生中断。

02

稳定性大滑坡，从理所当然到心存疑虑

然而，越是依赖，问题出现时产生的影响也越大。

图源：网络

过去一年里，围绕 GitHub 的一个高频词是「宕机」。不少第三方监测服务重建了 GitHub 的状态数据后发现，2025 年整体可用性已经跌破 90%，而 2026 年 4 月甚至不足 80%。

图源：网络

跟传统云服务商 99.9% 和 99.99% 的稳定性目标比，这几乎是一个不可接受的数字。与此同时，官方状态页长期给出的却是 99%+，这种感知与公告之间的落差，让很多开发者产生了「你到底是怎么算的」的怀疑。

4 月下旬的一连串事故，更像是压垮耐心的几根稻草：

• 4 月 23 日，GitHub 的合并队列出现严重回归，使用 squash merge 且合并多个 PR 的队列，会在后续合并时悄悄把之前的提交回滚掉。官方后续披露，共有 658 个仓库、2092 个 PR 受到影响。虽然 Git 层面没有数据丢失，但默认分支的状态被破坏，而且很多仓库无法安全自动恢复，需要维护者手动修补历史。

• 4 月 27 日，支撑 PR、Issue、Projects 等多个界面搜索的 Elasticsearch 集群因疑似 botnet 攻击过载，导致相关 UI 无法返回结果。Git 操作和 API 虽然未受波及，但日常工作大量依赖的搜索突然变成空白，对使用体验打击极大。

• 同一时间，安全公司 Wiz 对 GitHub 的 git 基础设施进行逆向分析，在 48 小时内挖出一个高危漏洞（CVE-2026-3854）：通过构造恶意 push options，远程攻击者可以获得对私有仓库的读写访问。好消息是 GitHub 在披露后 6 小时内完成修复，也没有发现被实际利用；坏消息是，这类内部服务盲信用户输入的架构级漏洞，暴露出平台的隐患。

单看每一个事件，GitHub 工程团队的响应速度和复盘流程都谈不上失职；但对每天都在用的开发者来说，一天工作 8 小时，有 1〜2 小时被各类排队进程、恢复进程拖住，久而久之难免会觉得这是一个不再值得信任的平台。

图源：GitHub

不久前，GitHub CTO 还发布了一篇「可用性更新」的长文，在文章中表示公司在 2025 年就启动了扩大 10 倍容量的计划，但很快发现这样的扩容计划依然远远不够；自 2025 年底起，自动化工作流、大仓库操作、接口调用等各项指标都在急剧上升，远超他们扩容 10 倍的规划，实际上应该按「30 倍」的负载去设计。

于是，GitHub 加速推进了一系列补救工程，但问题是对大部分开发者来说，感知就是现实。只要日常工作几乎每天都有一两个小时被 Actions、搜索、PR 审查等问题卡住，再漂亮的补救计划和道歉信都很难立刻重建信任。

知名开发者 Hashimoto 与 GitHub 的一封分手信

在这样的背景下，HashiCorp 联合创始人、Vagrant / Terraform 作者 Mitchell Hashimoto 的公开出走，就成了一个标志性的事件。

图源：Hashimoto

他是 GitHub 的早期用户，他的用户 ID 是 1299，这个数字就足以说明他注册 GitHub 的时间有多早，他也是那种真正把 GitHub 当精神家园的开发者。按他自己的话说，他大学熬夜、度假、甚至度蜜月时都会刷一下 GitHub，他把浏览 Issue、研究别的项目的维护流程当成乐趣。GitHub 是让他最开心的地方，甚至一度想去 GitHub 工作，成为这家公司的一份子。

图源：Hashimoto

但在 4 月的那篇博文里，他承认自己已经愤怒很久。他自己在过去一个月做了个小实验，只要 GitHub 的故障影响到他的工作，就在当天的日历上打一个「X」，结果一个月下来几乎每天都有 X。在写那篇文章的当天，他因为 GitHub Actions 故障，整整两个小时无法做任何 PR Review。于是他做出了将当前最重要的开源项目 Ghostty 迁出 GitHub 的决定，只在原仓库保留一个只读镜像。

在文章中，他直接用了「这里不再是一个适合我的地方」这样的措辞。

如果连一个长期深度绑定 GitHub、公开向平台表达过自己喜爱的开发者都觉得无法在这里完成工作，那其他团队也得开始重新审视自己对单一平台的依赖风险。

偏偏选在这个时候，Copilot 更改计费方式

就在稳定性争议、信任危机还在发酵的同时，GitHub Copilot 的计费模式调整，又进一步加重了开发者对平台的负面观感。4 月底 GitHub 正式宣布，从 2026 年 6 月 1 日起，所有 Copilot 计划将统一改为按用量计费。

图源：GitHub

从财务角度看，改成按 token 计费几乎是必然的。如今，长会话的智能体、仓库级代码改写，本身就意味着远高于过去一两次提示补全的推理开销。继续按每月 XX 次请求这样简单粗暴的方式收费，只会让服务长期亏损，拖累整个业务线。这一点，从其他大模型厂商的价格上调、配额收紧也能看到同样的趋势。

但对很多开发者和团队来说，GitHub 选择在这个时间点宣布调整，对外给人的观感就很复杂了。一方面，是大家刚刚经历了一连串平台不稳定的负面体验，官方还在发长文道歉，情绪上很难对要向你收取更多费用的平台抱有太多好感；另一方面，token 消耗本身对普通用户来说依然相当抽象，成本非常不透明，一个简单请求背后的实际 token 消耗量可能远超想象，那么产生的账单可能同样会超出预期，也会让不让用户对未来几个月的成本产生焦虑。

至少对平台上的用户来说，他们看到的是 GitHub 一边把大量工程资源和算力砸向 Copilot、智能体、Copilot Everywhere，另一边却连稳定地托管和协作代码这种最基础的服务都做不好。

结尾

GitHub 已经走过了从小团队创新产品，到行业基础设施、再到被微软收购并深入整合的完整一圈。它极大地推动了开源协作方式的演进，也改变了一整代开发者的学习路径和职业轨迹。正因为贡献巨大，人们才会对它的状态格外敏感。

稳定性滑坡、合并队列事故、安全漏洞、重要项目迁出、计费调整，最近一连串事件让很多人第一次认真思考一个此前几乎不需要问的问题：如果有一天 GitHub 不再那么可靠，我的开发工作该如何继续？

GitHub 高层在博文中反复强调自己的优先级顺序是可用性第一，其次是容量，再之后才是新功能，也开始公开更多状态数据、承诺增加透明度。GitHub 还能否重新赢回开发者的心呢？