Linux 内核官方 Git 仓库 git.kernel.org 近日披露了一组反常数据：在 5 个地理分布节点上，约有 14 个 CPU 核心同时用于把 Git 提交渲染成 HTML，服务对象主要是滥用型爬虫。按 CPU 消耗计算，这类抓取已经超过 Git 克隆在内的全部正常访问。
这件事的关键不在“14 个核心”这个数字本身。它暴露的是开放代码基础设施的一笔隐性账单：网页越适合索引，越容易被自动化程序反复读取；而渲染、带宽和运维成本，通常由提供公共服务的一方承担。
git.kernel.org：提交页面的渲染开销压过了 Git 克隆
Konstantin Ryabitsev 在一篇题为 《Creepy crawlies》 的文章中，谈到了 git.kernel.org 的运行情况。git.kernel.org 是 Linux 内核官方 Git 仓库，承担内核源代码和提交历史的公开访问。
他的判断很具体：在 5 个地理分布节点中，任何时点大约都有 14 个 CPU 核心“什么也不做”，只是在为爬虫渲染 Git 提交页面的 HTML。这里说的是观察到的 CPU 占用，不是全站总算力，也不是服务器已经濒临宕机。
更反常的地方在于访问类型的差异：
| 访问方式 | 主要用途 | 典型成本 |
|---|---|---|
| Git clone | 开发者、镜像站获取仓库数据 | 传输 Git 对象，通常不需要逐页生成 HTML |
| 人类浏览提交页面 | 查看 diff、提交说明和文件变化 | 需要网页渲染，但请求量相对有限 |
| 自动抓取提交 HTML | 建立索引、复制页面或处理数据 | 反复触发服务端渲染，成本可能快速累积 |
这和“爬虫占了不少网页流量”不是一回事。Ryabitsev 描述的是：爬虫造成的提交页面渲染成本，已经高于包括 Git clone 在内的其他合法访问。换句话说，服务端最忙的部分，可能不是开发者真正使用仓库的方式。
文章没有公布爬虫的来源、身份和用途。它也没有说明流量增长了多少、14 个核心占整个集群的比例，或者最终多花了多少钱。把这件事直接归因于 AI 训练公司，甚至据此宣称 Linux 项目遭遇运行危机，都超出了现有材料能够支持的范围。
开放代码站点很难用“一刀切”解决抓取问题
对代码托管服务来说，Git 协议和网页访问本来就是两套不同的路径。维护者可以限制某些网页请求，却不能轻易把搜索引擎、镜像站、发行版打包系统和普通开发者混在一起封掉。
robots.txt 只能表达站点意愿，不能约束不遵守规则的程序。限流和封禁更有效，却会遇到几个现实问题：
- 搜索索引需要读取公开提交页面；
- 镜像站可能从网页或接口补齐元数据；
- 企业内部工具和 CI 系统也可能使用自动化请求；
- 公共仓库往往不想为了防滥用而增加登录门槛。
GitHub、GitLab 等代码托管平台通常也会把网页浏览、API 调用和仓库克隆分开管理。这种分层能帮助运营者识别访问类型，却不能消除一个基础矛盾：只要 HTML 页面公开、结构稳定、容易批量访问，服务端就可能替抓取方承担解析和渲染费用。
因此，真正可行的方向通常不是单独加一条封禁规则，而是让不同访问方式付出不同成本。比如，为机器读取提供更适合的原始数据接口；对提交页面设置更细的缓存和请求频率控制；对异常客户端要求验证；把高成本渲染从主服务节点隔离出去。
这些措施都有代价。缓存可能延迟页面更新，验证可能误伤无头浏览器和自动化工具，接口调整也会影响已有镜像脚本。开放基础设施的难处，正在于它必须同时服务“想看一页提交的人”和“需要同步整个仓库的机器”。
维护者和数据网站开发者会先遇到预算问题
这件事最直接影响的，是两类运营者。
对 Linux 这类公共代码基础设施的维护者而言，接下来要看的不是单次流量峰值，而是请求是否集中在少数 URL、是否绕过缓存、是否持续触发昂贵的 HTML 渲染。若确认是固定模式的滥用抓取，优先处理的可能是提交页的缓存、速率限制和机器可读接口，而不是立即封掉所有自动化访问。
对运营 Datasette 这类高页面基数数据网站的开发者，风险更容易被低估。一个数据库发布成数万甚至数百万个可索引页面后，单个页面成本看起来很低，批量抓取就可能把 CPU 和带宽预算推到另一档。用户看到的只是“页面能不能打开”，运营者还要承担每次查询、模板渲染、排序和分页的服务器成本。
这会改变一些实际决策：
- 小项目不必因为一次爬虫异常就立刻迁移平台，但应记录按 User-Agent、IP、路径和响应时间划分的资源消耗；
- 页面规模较大的项目，最好把浏览页面和批量导出分开设计，给机器使用 CSV、JSON 或数据库快照等更低成本路径；
- 如果托管费用已经主要来自自动化请求，团队需要重新评估是否继续提供全部页面的匿名实时渲染，而不是只盯着访问量增长。
对普通开发者来说，短期内通常不会因为这条消息改变 Git clone 或浏览 Linux 提交的习惯。真正可能变化的是公共站点的访问策略：高频匿名请求会更容易遇到限速，镜像和内部工具也可能需要改用官方推荐的 Git 或 API 路径。
目前最值得观察的变量有三个：git.kernel.org 是否公开更完整的流量来源和资源占比；爬虫是否遵守站点规则；运营者最终采用的是缓存、接口分流还是访问验证。只有这些信息补齐后，才能判断这是一轮可控的运维优化，还是开放代码服务长期成本结构已经发生了变化。