GitHub把下载数据藏了5年，开发者被逼自己写了个追踪器

GitHub上有个数字，99%的开发者从没见过——你的二进制文件每天被下载多少次。

不是star数。不是fork数。是实实在在的下载量，有人运行过你代码的证据。

GitHub只显示当前累计总数，没有历史曲线。这意味着：你的项目可能在三个月前突然爆红，而你永远不会知道。开源维护者David Bernard管这叫"flying blind"——开着飞机，仪表盘是黑的。

他维护kubectl-view-allocations（一个Kubernetes资源查看工具）五年，直到去年才发现一个诡异现象：2025年12月到2026年1月，下载量毫无征兆地翻倍。没有新版本发布，没有官方公告，没有任何他能追踪到的传播节点。"Something spread it"，他在博客里写，"a newsletter, someone's blog post, a company's internal tooling. I have no idea what."

为什么star数是安慰剂

Bernard算过一笔账：500个star的项目，可能只有3个真实用户。人们收藏仓库的理由千奇百怪——"以后可能用得上""作者名气大""界面好看"，但收藏和运行是两回事。

npm、crates.io、PyPI这些包管理器能告诉你库文件（library）的下载情况，但二进制工具（binary）的发布走的是另一条通道：GitHub Releases。那里藏着大量预编译的可执行文件，而官方不提供任何历史趋势。

这就导致一个荒诞的局面：你花周末写的命令行工具被某家公司的CI系统每天调用上千次，你自己却以为没人用，差点放弃维护。

Bernard的另一个项目ffizer就是反面教材。新版本发布后下载量几乎为零——这不是产品问题，是认知问题。诊断错了，解法就全错。

download-history：一个维护者的自救工具

解决方案简单粗暴：每几小时爬一次GitHub API，存成每日快照，画成趋势图。Bernard把它做成在线服务download-history.cdviz.dev，输入owner/repo就能看60天曲线。

图表支持交互式浏览，也能生成静态SVG嵌入README，每天自动更新。他放了个示例代码：


这个工具对私有仓库也有效，只需要提供access token。定价策略很"个人开发者"：14天免费试用，不需要信用卡，不需要注册。之后每年5欧元，最多追踪2个仓库。

Bernard拿jdx/mise（一个多语言版本管理器，非他本人项目）当参考案例。这个工具发布频率极高，每1-5天一个新版本，被CI和桌面环境持续拉取。它的下载曲线没有明显尖峰——因为用户不是"升级时下载一次"，而是"每次运行都可能拉最新版"。

同样的图表，不同的读法。上下文决定你怎么理解数据。

数据不会告诉你答案，但会给你更好的问题

Bernard在文章结尾列了下一步计划：支持GitHub Packages（容器、npm、Maven），可能拓展到GitLab。然后抛出一个开放问题："What metrics do you track for your OSS projects? I'm curious what signals actually matter to other maintainers."

这个问题背后是整个开源生态的度量困境。我们习惯了用star数证明项目健康，用贡献者数量显示社区活跃，但这些指标和真实采用率之间的裂缝越来越大。

一个更尖锐的版本是：当你的项目被集成进某家巨头的内部工具链，却没有任何外部可见性时，你该怎么证明它的价值？

Bernard的工具解决的是技术层面的盲区，但更大的盲区在于——开源维护者至今没有行业共识的"健康度指标"。下载量、活跃issue数、响应速度、依赖该项目的其他仓库数量……每个维度都有漏洞，组合起来又过于复杂。

他的14天免费试用不需要注册，这个设计本身就有趣。意味着你可以偷偷查任何公开项目的真实下载趋势，包括竞争对手。开源世界的信息不对称，正在被这种小工具一点点削平。

你在维护什么项目？如果突然能看到过去一年的下载曲线，你最想验证哪个假设——是某个功能真的没人用，还是某个你放弃的旧版本其实还在被大量调用？