GitHub.com 出现故障时，一个反常细节很快被开发者注意到：网页、部分 API 或下载入口异常，Git 仓库的读写却没有同步瘫痪。
这件事比“GitHub 崩了”更值得看。因为“GitHub”从来不是一个服务。它至少包含网页端、API、Git over HTTPS、Git over SSH、Actions、Release 下载、raw 文件分发和身份认证。它们看起来属于同一个产品，背后却可能经过不同的服务层、缓存层和网络入口。
所以，标题里那句“命令行没崩”并不严谨。git clone 或 git push 走的是 Git 协议；gh pr list、gh issue view 仍然依赖 GitHub API。前者正常，不代表所有命令行工具都正常。
故障到底影响了什么
从现有事件线索看，能确认的范围主要是入口之间出现了差异：
| 入口或功能 | 可能表现 | 对用户的直接影响 |
|---|---|---|
| GitHub 网页 | 页面打不开、加载失败或响应异常 | 无法浏览仓库、提交 PR、查看 Issue |
| GitHub API | 请求失败、超时或返回错误 | gh、CI 集成和自动化脚本可能受影响 |
| Git over HTTPS / SSH | 部分 Git 操作仍可用 | 可以继续拉取、提交和推送代码，但不能据此判断全站正常 |
| Release、raw 下载 | 可能与网页状态不同步 | 安装脚本、依赖下载和构建流程可能失败 |
| GitHub Actions | 取决于调度、认证和依赖服务 | 已在运行的任务、待执行任务可能出现不同结果 |
目前没有足够证据证明这些入口共用同一个资源池，也不能仅凭“Git 操作正常、网页异常”断言根因已经定位。更稳妥的判断是：故障影响了应用层或某些边缘入口，但 Git 数据面没有完全失效。
这一区分很现实。
如果你只是查看代码，网页打不开会让人烦；如果你正在发布版本，Release 下载失败可能让用户拿不到安装包；如果团队的 CI 依赖 API 拉取变量、创建状态检查或下载构建依赖，问题就会从“网页打不开”变成流水线停摆。
事件是否已经恢复，也不能只看某一次访问结果。应以 GitHub Status 的 incident 页面和自己的实际请求为准。公共状态页通常有延迟，个别地区的缓存和网络路径也可能让用户看到不同结果。
开发者现在该怎么判断
遇到类似故障，别只反复刷新 github.com。按功能拆开检查，结果更接近事实：
git ls-remote git@github.com:OWNER/REPO.git
git ls-remote https://github.com/OWNER/REPO.git
gh api rate_limit
curl -I https://raw.githubusercontent.com/OWNER/REPO/REF/path这几条命令分别触及 SSH、HTTPS、API 和 raw 下载入口。它们的结果不能替代官方状态页，但能告诉你自己的网络、凭证和目标服务是否同时受影响。
团队可以据此做出不同动作：
- Git 读写正常、API 异常.先继续本地提交和推送，暂停依赖
gh或 API 的自动化操作。 - Git 正常、Release 或 raw 下载异常：不要临时发布新的安装说明，先检查构建产物和下载地址。
- SSH 与 HTTPS 结果不同.优先保留能工作的协议，同时检查企业代理、凭证和网络出口。
- Actions 或 API 持续失败.把关键任务转到已有缓存、制品库或镜像，不要让重试脚本无限放大请求量。
- 正在做紧急发布.把源码、制品、部署凭证和回滚包放在团队自己控制的存储中，避免把最后一步也押在 GitHub 上。
这里有一个容易被忽略的限制：备用入口不等于备用系统。你在对象存储里保存了构建包，却仍然需要 GitHub 身份认证；你能通过 SSH 推送代码，却未必能创建 PR 或触发依赖 API 的部署流程。真正的应急能力，取决于整条链路能否脱离单一平台完成。
GitHub 把复杂性藏得很好
GitHub 的产品体验一直在做一件事：把仓库、协作、构建、发布和权限塞进一个网址。对日常使用来说，这是效率；对故障排查来说，却容易产生错觉，仿佛所有功能共享同一个“开关”。
历史上的大型互联网服务也反复证明这一点。用户看到的是一个品牌，工程师面对的是许多不同的故障域。网络边缘、身份系统、数据库、任务调度和文件分发可以分别出问题。所谓“局部可用”，并不奇怪；真正困难的是判断哪条链路还值得继续依赖。
这次事件至少说明了一件事：GitHub 的故障隔离做得比表面看上去更细，或者说，某些关键数据面没有跟着应用入口一起倒下。这是一个偏正面的工程信号。但它也暴露了另一个现实：开发者把网页端的便利，误认为了平台整体的可靠性。
我不太买账的是“命令行没崩，所以影响不大”这种说法。
对个人开发者，能 push 确实能争取时间。对企业团队，认证、Actions、API、制品下载才可能是最贵的环节。一次短暂的网页故障，未必造成严重损失；一次认证服务或构建依赖故障，却可能让一整批发布任务排队，甚至让值班工程师只能手工接管。
GitHub 这次真正值得观察的变量，不是页面何时恢复，而是后续事件报告会不会把故障边界讲清楚：
- 哪些入口实际受影响，哪些只是区域性异常；
- Git、API、Actions 和下载服务之间的依赖关系；
- 重试、缓存和降级机制是否真的生效；
- 用户有没有得到足够具体的操作建议，而不只是“正在调查”。
平台越方便，团队越容易把关键流程交给它。方便会积累依赖，依赖会转化成议价权，也会转化成单点风险。GitHub 这次没有全线倒下，恰好让那条边界被看见了。
这比一句“服务已恢复”更有价值。