一位用了18年、编号1299的老用户，开始记日记统计平台故障——几乎每天都有叉号。

从"doom scrolling"到"downtime logging"

打开网易新闻 查看精彩图片

Mitchell Hashimoto在博客开篇回忆："每天多次打开GitHub，持续了18年多。"他说这是自己最开心的地方，"早在'doom scrolling'这个词出现之前，我就已经在GitHub issues里这么干了。"

这种情感浓度，来自2008年的早期用户身份。GitHub第1299个账号，意味着他比绝大多数开发者更早押注这个平台。

但过去一个月，Hashimoto开始执行一项残酷的记录：每当GitHub故障影响工作，就在日记里画个"X"。

结果是：几乎每天都有叉号。写博客当天，GitHub Actions故障导致他约2小时无法审查PR。"如果每天把你挡在外面几小时，这就不再是严肃工作的地方了。"

故障日志背后的生产环境痛点

Hashimoto的遭遇不是孤例。原文提到，从小型爱好者到大型企业，近期都被GitHub的稳定性问题波及——OpenAI reportedly考虑过自建代码托管平台，只为确保随时能访问自己的代码。

终端软件Ghostty的特殊性在于：它既是Hashimoto的主力项目，也是开发者高频使用的工具类产品。这类项目对CI/CD（持续集成/持续部署）的依赖极重，GitHub Actions的每一次宕机都直接阻断版本迭代。

Hashimoto的应对策略呈现明显的分层：

个人项目留守GitHub——情感账户和轻量需求仍在；核心工作迁移别处——生产环境不容忍"几乎每天"的不可用。

但他坦承："还不知道Ghostty会搬去哪里。"这种不确定性本身，构成了事件的最大悬念。

平台迁移的连锁反应

Hashimoto的离开姿态留有余地："如果GitHub整顿好，愿意回来。"但"暂时不会在那里托管关键工作"的表述，已经将信任降级为临时状态。

对于Ghostty这类开源终端工具，托管平台的切换涉及多重迁移成本：issue历史、PR记录、Actions工作流重构、社区协作习惯的打破。Hashimoto仍决定推进，说明故障频率已越过成本收益的临界点。

更值得观察的是去向的空白。GitLab、SourceHut、Codeberg，或自托管Forgejo？每个选项都对应不同的治理哲学和社区生态。Hashimoto的终极选择，将成为其他重度GitHub用户的决策参考。

一个用了18年的第1299号用户开始画叉计数，这件事本身就是平台信任崩塌的量化指标。