GitHub 与软件之罪

# githubbad.html 来源：https://eblog.fly.dev/githubbad.html https://eblog.fly.dev/githubbad.html#github-and-the-crime-against-software ## 关于软件之罪：GitHub（https://eblog.fly.dev/githubbad.html#github-and-the-crime-against-software） 一份软件文章，作者：Efron Licht，2026年5月 https://eblog.fly.dev/githubbad.html#all-articles-index-html ### https://eblog.fly.dev/githubbad.html#all-articles-index-html **全部文章**（https://eblog.fly.dev/index.html） https://eblog.fly.dev/githubbad.html#license-license-html ### https://eblog.fly.dev/githubbad.html#license-license-html **许可协议**（https://eblog.fly.dev/license.html） https://eblog.fly.dev/githubbad.html#feeds ### 订阅源（https://eblog.fly.dev/githubbad.html#feeds） - RSS（https://eblog.fly.dev/feed.rss.xml） - ATOM（https://eblog.fly.dev/feed.atom.xml） - JSON（https://eblog.fly.dev/feed.json） https://eblog.fly.dev/githubbad.html#introduction ## 引言（https://eblog.fly.dev/githubbad.html#introduction） > 如果房子着火，只会有两方：一方主张灭火，另一方则希望房子烧掉。（https://presidentlincoln.illinois.gov/lincoln-quotes/?sort=1a&pg=1&sz=10&q=house%20burning）**亚伯拉罕·林肯** 当我开始写这篇文章时，GitHub 又宕机了。虽然已经有很多文章在讨论 GitHub 在可靠性、安全性和性能方面的问题，例如 The Verge 的这篇（https://www.theverge.com/tech/935250/microsoft-github-struggles-notepad），但它们仅仅触及了表面。GitHub 就像某种“信号”，反映了 GitHub 本身以及整个大型科技软件服务领域基础设施的衰败。虽然我也可以指出从 AWS 到 Google 搜索等几乎所有大型科技企业服务中都存在类似的衰败，但 GitHub 因为几乎成了软件开发的代名词而成为一个引人注目的例子。我记得 2022 年与一位招聘人员的对话，他们根本不相信我是一名“真正的程序员”，就因为我没有 GitHub 账号。 GitHub 本应是一个高性能、高可用、高容量的分布式系统——这正是我的个人专业领域，因此我能比普通科技记者更深入地洞察问题所在。 问题不仅仅是可用性：GitHub 充满了各种毛病。以下列举（部分），**加粗**部分将有证据支持。 https://eblog.fly.dev/githubbad.html#a-small-sample-of-recent-problems-with-github ## GitHub 近期问题之小样本（https://eblog.fly.dev/githubbad.html#a-small-sample-of-recent-problems-with-github） - **根据 GitHub 自己的公开通信，每月发生数十起事故**（https://www.githubstatus.com/history），这意味着实际数量可能数以百计。 - GitHub 不公开 Bug 列表或任何问题页面，将问题深藏在邮件链中。 - **GitHub 不断向用户撒谎，关于其正常运行时间和优先级**——即使按照它自己的指标（https://www.githubstatus.com/），它也违反了服务级别协议（SLA）（https://github.com/customer-terms/github-online-services-sla）。 - **GitHub 明显优先考虑花哨的 AI 功能，而非基本可靠性**。 - **“代理化”负载的增加，直接源于 GitHub 自身及其母公司 Microsoft 的行为，因此可靠性问题完全是其自身过错**。 - GitHub 经常在 Firefox 和 Safari 上崩溃，这些浏览器拥有数百万用户。 - GitHub 容忍其服务上的明显“买粉丝”和“买星”行为，并推广明显是假象的仓库：甚至有一个名为 githubstars.com（https://githubstars.com/）的网站公开宣传买星，参见卡内基梅隆大学发表的这篇论文（https://arxiv.org/pdf/2412.13459v1），尽管引用文称“虚假星星与恶意活动高度相关”。 - GitHub 的拉取请求页面（尤其是评论/审查页面）响应缓慢，且内存占用极高（我曾见过堆内存峰值超过 512 MiB！） - GitHub 经常重置或更改项目及用户设置：新功能默认“开启”，即使极其危险。 - GitHub 明显优先考虑花哨的“AI”项目，而非实际付费用户。 - GitHub Actions 设计糟糕、运行缓慢且文档不全，很可能是所有“用 YAML 写 shell 脚本”式构建系统中表现最差的——我见过几十种类似系统。 - GitHub Actions 日志存在内存泄漏，多年来曾多次导致我的浏览器崩溃，目前仍没有直接将 stdout 管道输出的方法。 - GitHub 的“默认”操作（例如 setup-go（https://github.com/actions/setup-go）的默认缓存行为极其天真，甚至不如没有；其中许多操作从不进行缓存失效。 > 我可以一直说下去。用著名的 PHP 吐槽（https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/）来说，这是坏设计的分形结构。 - **GitHub 的前端……** - **臃肿慢速得可笑**——经常在 Safari 和 Firefox 上崩溃。 - **不断更改用户体验，毫无警告或解释**，往往有意用更多通向其“AI”系统的漏斗取代过去有用的 UX 部分。 https://eblog.fly.dev/githubbad.html#table-of-contents ## 目录（https://eblog.fly.dev/githubbad.html#table-of-contents） *自动生成于 2026-05-29* - 引言（https://eblog.fly.dev/githubbad.html#introduction） - GitHub 近期问题之小样本（https://eblog.fly.dev/githubbad.html#a-small-sample-of-recent-problems-with-github） - GitHub 不断向用户撒谎，关于其正常运行时间和优先级（https://eblog.fly.dev/githubbad.html#github-constantly-lies-to-its-users-about-it-s-uptime-and-priorities） - 代理化负载增加的直接原因（https://eblog.fly.dev/githubbad.html#the-increased-agentic-load-on-github-is-the-direct-result-of-their-own-actions-and-those-of-their-parent-company-microsoft） - GitHub 的前端代码一团糟：GitHub、GitLab 与 Codeberg 对比（https://eblog.fly.dev/githubbad.html#github-s-front-end-code-is-a-mess-comparisons-of-github-gitlab-and-codeberg） - 图片：仓库着陆页（GitHub、GitLab、Codeberg）（https://eblog.fly.dev/githubbad.html#images-repository-landing-page-for-github-gitlab-codeberg） - 实验设计（https://eblog.fly.dev/githubbad.html#experiment-design） - 实验步骤（https://eblog.fly.dev/githubbad.html#experiment-procedure） - 运行实验（https://eblog.fly.dev/githubbad.html#running-the-experiment） - 创建仓库（https://eblog.fly.dev/githubbad.html#creating-the-repo） - 将仓库上传至 GitHub、GitLab 与 Codeberg（https://eblog.fly.dev/githubbad.html#uploading-the-repo-to-github-gitlab-and-codeberg） - 收集网络样本数据（https://eblog.fly.dev/githubbad.html#collecting-network-sample-data） - 收集加载后的堆内存使用情况（https://eblog.fly.dev/githubbad.html#collect-heap-ram-usage-after-load） - 堆内存使用分析与历史对比（https://eblog.fly.dev/githubbad.html#anaysis-of-heap-usage-and-historical-comparisons） - 使用 testcompress 收集压缩支持信息（https://eblog.fly.dev/githubbad.html#use-testcompress-to-collect-information-on-compression-support） - 使用 anhar 分析网络存档（HAR）（https://eblog.fly.dev/githubbad.html#analyzing-the-network-archive-har-with-anhar） - 小节·1（https://eblog.fly.dev/githubbad.html#in-1） - 各节说明（https://eblog.fly.dev/githubbad.html#explanation-of-sections） - 引理：这不仅仅是“屎化”（https://eblog.fly.dev/githubbad.html#lemma-it-s-not-mere-enshittification） - 第三方分析：PageSpeed Web Dev（https://eblog.fly.dev/githubbad.html#third-party-analysis-pagespeed-web-dev） - 移动端（https://eblog.fly.dev/githubbad.html#mobile） - PageSpeed 提供了极好的性能改进建议——随着阅读我会突出一些更有趣的点以及我自己的思考（https://eblog.fly.dev/githubbad.html#pagespeed-has-great-recommendations-on-how-to-improve-performance-i-ll-highlight-some-of-the-more-interesting-ones-and-my-own-thoughts-as-we-go-along） - GitHub、GitLab 与 Codeberg 的对比（https://eblog.fly.dev/githubbad.html#comparison-of-github-gitlab-and-codeberg） - GitLab（https://eblog.fly.dev/githubbad.html#gitlab） - 总结（https://eblog.fly.dev/githubbad.html#summary） - 评分：D（https://eblog.fly.dev/githubbad.html#grade-d） - 建议·开发者（https://eblog.fly.dev/githubbad.html#suggestions-developer） - 建议·用户（https://eblog.fly.dev/githubbad.html#suggestions-user） - Codeberg / Forgejo（https://eblog.fly.dev/githubbad.html#codeberg-forgejo） - 总结·1（https://eblog.fly.dev/githubbad.html#summary-1） - 评分：C（https://eblog.fly.dev/githubbad.html#grade-c） - 建议·开发者·1（https://eblog.fly.dev/githubbad.html#suggestions-developer-1） - 建议·用户·1（https://eblog.fly.dev/githubbad.html#suggestions-user-1） - 评论（https://eblog.fly.dev/githubbad.html#commentary） - GitHub（https://eblog.fly.dev/githubbad.html#github） - 总结·2（https://eblog.fly.dev/githubbad.html#summary-2） - 评分：F（https://eblog.fly.dev/githubbad.html#grade-f） - 评论·1（https://eblog.fly.dev/githubbad.html#commentary-1） - 建议·开发者·2（https://eblog.fly.dev/githubbad.html#suggestions-developer-2） - 建议·用户·2（https://eblog.fly.dev/githubbad.html#suggestions-user-2） - eblog.fly.dev/startingsystems3.html（https://eblog.fly.dev/githubbad.html#eblog-fly-dev-startingsystems3-html） - 总结·3（https://eblog.fly.dev/githubbad.html#summary-3） - 评分：A（https://eblog.fly.dev/githubbad.html#grade-a） - 建议·开发者·3（https://eblog.fly.dev/githubbad.html#suggestions-developer-3） - 建议·用户·3（https://eblog.fly.dev/githubbad.html#suggestions-user-3） - 结论（https://eblog.fly.dev/githubbad.html#conclusion） - 附录（https://eblog.fly.dev/githubbad.html#appendix） - anhar 源码（https://eblog.fly.dev/githubbad.html#anhar-source） - anhar 结果（https://eblog.fly.dev/githubbad.html#anhar-results） - 额外内容：testcompress（https://eblog.fly.dev/githubbad.html#bonus-content-testcompress） - testcompress 源码（https://eblog.fly.dev/githubbad.html#testcompress-source） - 额外内容：testcompress 结果（https://eblog.fly.dev/githubbad.html#bonus-content-testcompress-results） https://eblog.fly.dev/githubbad.html#github-constantly-lies-to-its-users-about-it-s-uptime-and-priorities ## GitHub 不断向用户撒谎，关于其正常运行时间和优先级（https://eblog.fly.dev/githubbad.html#github-constantly-lies-to-its-users-about-it-s-uptime-and-priorities） 虽然 GitHub 的官方状态页面（https://www.githubstatus.com/）声称有大约 99.8% 的正常运行时间——但任何最近使用过它的人都知道实际数字中一个“9”也没有。像“缺失的 GitHub 状态页面”（https://mrshu.github.io/github-statuses/）这样的网站很好地展示了真实情况。 “缺失的 GitHub 状态页面”，显示可用性为 87.06% GitHub 非常清楚自己最近处境艰难，并发布了一些新闻稿试图转移批评。上个月，GitHub 发布了一篇题为“关于 GitHub 可用性的更新”（https://github.blog/news-insights/company-news/an-update-on-github-availability/）的新闻稿，试图回应部分批评。 > 微软：*主要驱动力是软件构建方式的急剧变化。自 2025 年 12 月下半月以来，代理化开发工作流急剧加速。几乎从所有指标来看，趋势已经明确：仓库创建、拉取请求活动、API 使用、自动化和大型仓库工作负载都在快速增长。* > GitHub 展示其工作负载数量的图表 除了一个没有标注坐标轴或具体数据点的图表总是值得怀疑之外，使用被动语态说“代理化开发工作流急剧加速”简直虚伪至极，好像这是悄悄发生在 GitHub 身上、未经其知晓或同意的事情。GitHub 归微软所有，而微软是一家将 AI（包括“代理”）以无数重叠的方式塞入每一款产品的公司。几乎每个 GitHub 页面在热栏中都有三个不同的 AI 按钮，其中两个完全用于启动代理。许多页面甚至有四个。 https://eblog.fly.dev/githubbad.html#the-increased-agentic-load-on-github-is-the-direct-result-of-their-own-actions-and-those-of-their-parent-company-microsoft ### “代理化”负载的增加直接源于 GitHub 自身及其母公司 Microsoft 的行为（https://eblog.fly.dev/githubbad.html#the-increased-agentic-load-on-github-is-the-direct-result-of-their-own-actions-and-those-of-their-parent-company-microsoft） > 人们被明智地认为会意图其行为的自然结果，并寻求其行为似乎促进的东西。——查尔斯·萨姆纳，《对堪萨斯的罪行》 GitHub 和微软不断推动用户在任何情况下使用“AI”和“代理”。 我们很难夸大他们有多希望你使用这些东西：在普通仓库着陆页的右上方四分之一区域内，就有四种不同的方式启动 Copilot。四种。 登录后的 GitHub 着陆页，带有两个不同的 AI 按钮 （在写这篇文章的过程中，我发现每个页面上还有第三个代理按钮。对于没有显式禁用代理的仓库项目，会出现第四个按钮。这简直是病态。） 登录后的 GitHub 着陆页，带有~~两个~~三个 AI 按钮。仓库页面在右上角有四个不同的 AI 按钮，其中三个用于启动代理——开玩笑吧？ 此外，GitHub 多年来一直补贴这些工具的使用成本，以推动采用率，这实际上相当于对自己发起分布式拒绝服务攻击（https://www.wheresyoured.at/news-microsoft-to-shift-github-copilot-users-to-token-based-billing-reduce-rate-limits-2/）。 > 微软：*这种指数级增长不会一次只给一个系统带来压力。一个拉取请求可能触及 Git 存储、可合并性检查、分支保护、GitHub Actions、搜索、通知、权限、Webhooks、API、后台任务、缓存和数据库。**在大规模下，小的低效会层层叠加**：队列加深，缓存未命中变成数据库负载，索引落后，重试放大流量，一个缓慢的依赖项可能影响多个产品体验。* GitHub 的数据库工程师并不轻松——这是一个真正的挑战，我自己也会觉得棘手——但 GitHub 的问题并非**小**的低效，而是巨大且惊人的低效，我们稍后会谈到。 > 微软：***我们的优先级很明确：可用性第一，容量第二，新功能第三。*** 这是一个谎言。**GitHub——以及更广泛的微软组织——明显优先考虑花哨的 AI 功能，而非基本可靠性**。GitHub 有一个公开的更改日志（https://github.blog/changelog/）。自他们发布更新以来的三十天里，补丁说明中包含“copilot”一词 59 次，“agent”8 次，“performance”0 次，“reliability”0 次。更改日志支持按类别筛选：Copilot 是一个独立类别；性能和可靠性则根本不存在。 这不仅仅局限于 GitHub 本身，而是整个组织普遍存在的问题。同样归微软所有的 Visual Studio Code 是世界上最流行的 IDE（代码编辑器），并且直接