大家好，我是Tony Bai。
在程序员的江湖里，GitHub 从来不仅仅是一个代码托管平台。它是开源精神的麦加，是数千万开发者的“赛博故乡”，是这个行业赖以运转的、最坚实的“基础设施”。
但就在近几个月，这座我们无比信赖的“圣城”，似乎正在走向“崩塌”。
4 月 28 日，Github 的第1299位用户，在自己的推特与博客上发表了一篇极其悲伤的“分手信”，标题是：《Ghostty Is Leaving GitHub》（Ghostty 正在离开 GitHub）。
这位用户，不是别人，正是 HashiCorp 的联合创始人、一手缔造了 Terraform、Vagrant、Vault、Consul 等一系列云原生和 Devops 神器的“教父级”人物——Mitchell Hashimoto。而 Ghostty，正是他当下倾注心血的、备受期待的新一代终端项目。
他在这封信中，用一种近乎“心碎”的口吻写道：
“写下这些让我感到莫名的悲伤。我从 2008 年 2 月开始使用 GitHub，至今已超过 18 年，横跨了我半个人生。……我曾深爱着 GitHub，胜过一个人应该去爱一个东西。但现在，我受够了。18 年了，我得走了。”
是什么，让这位曾经的“ GitHub骨灰粉”毅然决然地带着自己的“亲儿子”项目“出走”呢？
答案简单得令人窒息：GitHub 正在变得越来越不可用。
“在过去的一个月里，我用日记记录了每一次 GitHub 宕机对我工作的影响。几乎每一天，旁边都画着一个‘X’。就在我写下这些文字的时候，GitHub Actions 又挂了 2 个小时。……如果一个平台每天都要瘫痪几个小时，那它就不再是一个适合严肃工作的地方。”
Mitchell 的这封“分手信”，像一颗炸弹，瞬间引爆了整个技术圈。
就在文章发布的几个小时后，GitHub 的 CTO Vlad Fedorov 紧急发表了一篇官方博客，标题同样沉重：《An update on GitHub availability》（关于 GitHub 可用性的更新）。
在这篇近乎“道歉信”的回应中，GitHub 官方不仅承认了问题的严重性，更罕见地揭示了这场“可用性雪崩”背后的真正罪魁祸首，以及他们正在秘密进行的“技术自救”——其中，Go 语言扮演了至关重要的“救火队长”角色。
今天，就让我们来复盘一下这场由“分手信”引发的技术公案。
压垮骆驼的稻草：被 AI “撑爆”的古老架构
GitHub 到底怎么了？
在官方的回应中，CTO Vlad Fedorov 给我们展示了一张极其恐怖的增长曲线图：“Record Acceleration”（创纪录的加速）。
自 2025 年下半年以来，随着 AI Agent（智能体）编程工作流的急剧加速，GitHub 的各项核心指标都呈现出近乎垂直的指数级增长：
每月新增仓库数：2000 万
每月合并的 PR 数：9000 万
每月 Commits 数：14 亿
GitHub 官方坦言：
“这种指数级的增长，不是只对一个系统造成压力。一个 PR 会触及 Git 存储、合并检查、分支保护、GitHub Actions、搜索、通知、权限、API、后台任务、缓存和数据库。在巨大的规模下，微小的低效会被无限放大。”
队列加深、缓存击穿、索引落后……这些经典的分布式系统“并发症”，在 AI 制造的流量洪峰面前，被彻底引爆了。
Mitchell Hashimoto 的“出走”，只不过是压垮骆驼的最后一根稻草。
Go 语言的救赎：从 Ruby 单体地狱中“紧急救火”
面对这场史无前例的“流量洪水”，GitHub 的工程师们正在进行一场惊心动魄的“架构自救”。
在官方博客的What we're doing一小节中，我们看到了一个熟悉的身影——Go 语言。
“我们加速了将性能或规模敏感的代码，从 Ruby 单体应用中迁移到 Go 语言的过程。”
这短短的一句话，信息量巨大。它揭示了 GitHub 这座“上古神殿”最核心的技术债之一：一些庞大、沉重、且难以扩展的 Ruby 单体应用。
在过去，当我们需要提升性能时，可能会选择更深入地优化 Ruby 代码，或者在前面加更多的缓存。
但在 AI 时代，这种“小修小补”可能已经毫无意义了。面对 10 倍甚至 30 倍的流量增长预期，唯一的出路，就是对系统进行“外科手术式”的重构。
为什么选择 Go 来“救火”？
因为 Go 语言几乎是为这种“救火”场景量身定制的：
极致的性能与并发：Go 的性能远超 Ruby，其原生的 Goroutine 并发模型，能极其轻松地榨干现代多核服务器的性能，应对海量的网络请求。
极低的资源占用：相比于 Ruby 或 Python 这种动态语言，Go 的内存占用更小、更可控，能极大地降低服务器成本。
简单的部署：静态编译的单一二进制文件，使得将新的 Go 微服务部署到庞大的 Kubernetes 集群中，变得极其简单。
我们可以想象，在 GitHub 内部，正有无数个由 Go 语言编写的、小而美的微服务，像一支支训练有素的“消防队”，正在冲入火场，小心翼翼地从那个庞大的 Ruby 巨人身上，一块块地切下那些已经“燃烧”的性能瓶颈模块（如 Webhooks、认证授权、Git 操作等）。
Go 语言，正在成为 GitHub 这艘巨轮在 AI 洪流中，避免沉没的“压舱石”。
从“深情”到“决绝”：一个顶级开发者的 18 年之痒
Mitchell 的“分手信”，之所以能在社区引发如此巨大的共鸣，不仅仅是因为他的技术地位，更在于信中那份令人动容的“爱之深，责之切”。
他坦言，自己 20 岁时创建 Vagrant 这个成名作，很大程度上就是为了能获得一份在 GitHub 的工作。
“GitHub 是我的梦想。那里的工程师令人难以置信，产品令人难以置信。在过去的 18 年里，我每天都在呼吸着它的空气。”
“当我的感情经历挫折时，我把自己沉浸在 GitHub 的开源世界里；当我在大学里通宵时，我会在凌晨 4 点偷偷提交一个 commit；甚至在我的蜜月期间，我都会趁着妻子还在睡觉时，打开 GitHub。”
但正是这份深沉的爱，让 GitHub 的每一次宕机，都像一把刀子，刺在他的心上。
“这对我来说是私人的。我对 GitHub 的爱，超过了一个人应该对一个东西的爱。所以我对它感到愤怒。”
在文章的最后，他给所有“Git 是分布式的，你怕什么”的言论，给出了最沉重的回击：
“问题不在于 Git，而在于我们围绕它建立的、赖以为生的基础设施：Issues, PRs, Actions……如果它每天都要让你停工几个小时，那它就不再是一个适合严肃工作的地方。”
小结：当“基础设施”不再是理所当然
Mitchell Hashimoto 的“出走”，和 GitHub 官方的“道歉”，共同为我们揭示了 AI 时代一个极其深刻的现实：
当生产力工具的效率被提升 10 倍、100 倍时，它对底层基础设施稳定性的要求，也将被以同样指数级的规模放大。
我们曾经以为像水和电一样“理所当然”的 GitHub，正在成为整个行业发展的瓶颈。
这场危机，对 GitHub 来说是“生死存亡”的挑战，但对我们这些身处其中的技术人来说，又何尝不是一次“机遇”？
它告诉我们：
基础软件领域，永远有仗可打。当所有人都涌向应用层，去卷 AI Agent 的花活时，那些能用 Go 或 Rust，去重构和加固底层基础设施的硬核工程师，其价值将变得空前稀缺。
“稳定性”是最高的壁垒。在一个功能可以被 AI 瞬间生成的时代，一个系统的长期价值，越来越多地体现在它的可用性、可靠性和可扩展性上。
保持警惕，准备“B 计划”。将所有的鸡蛋都放在 GitHub 这一个篮子里，可能不再是一个明智的选择。无论是自建 GitLab或Forgejo，还是探索其他新兴的代码协作平台，都值得我们重新审视。
旧神正在踉跄，新王尚未诞生。
在这场由 AI 引发的、史无前例的“基础设施大迁徙”中，你，准备好你的船票了吗？
资料链接：
https://mitchellh.com/writing/ghostty-leaving-github
https://github.blog/news-insights/company-news/an-update-on-github-availability/
https://x.com/mitchellh/status/2049213597419774026
👇 今日互动探讨：
在过去几个月里，你是否也曾被 GitHub 的频繁宕机所困扰？你认为 GitHub 这次“中年危机”的根源，真的是 AI 吗？还是其自身技术债的必然爆发？
欢迎在评论区分享你的看法！
如果本文对你有所帮助，请帮忙点赞、推荐和转发！
点击下面标题，干货！
- GitHub 的 99.9%，被 AI Agent 薅秃了
- AI 时代的开源：当 Coding Agent 接管 GitHub，我们该何去何从？
- 还在当“上下文搬运工”？我写了一门课，帮你重塑AI开发工作流
- Go 语言的“舒适区”：为何在这张“鄙视链”金字塔中，Go 仅次于 C？
- “我们想用 Rust 重写的次数是：零”：云平台 Render 靠“无聊”的 Go 撑起了千亿流量
- Ruby on Rails 之父最新访谈：AI 正在推高顶尖程序员的身价
- 通过实例理解Go Web身份认证的几种方式
🔥 还在为“复制粘贴喂AI”而烦恼？我的新极客时间专栏《AI原生开发工作流实战》将带你：
告别低效，重塑开发范式
驾驭AI Agent(Claude Code)，实现工作流自动化
从“AI使用者”进化为规范驱动开发的“工作流指挥家”
扫描下方二维码👇，开启你的AI原生开发之旅。
