GitHub 突发“隐私强控”：Star 历史图大面积挂了，我们该怎么办？

最近几天，不少细心的小伙伴在刷新 README 或者个人博客时，可能会发现一个尴尬的现象：那些用来展示项目“爆火程度”的 Star History（Star 历史趋势图）突然裂开了，只剩下一片空白或者报错。

这可不是你的网络出了问题，而是 GitHub 悄悄搞了一个大动作——收权。

🔒 事情起因：为了隐私，GitHub“动刀”了

就在 6 月 30 日，GitHub 官方悄然生效了一项新的 API 权限策略。这次调整的核心非常直接：限制非仓库所有者和贡献者读取 Star 列表和 Watcher 列表。

在此之前，只要是个路人甲，通过 API 都能扒下来某个热门项目的所有 Star 用户列表。虽然这方便开发者做数据统计和展示，但也带来了巨大的副作用——隐私泄露与骚扰。

受 GitHub API 权限调整影响，Star History 图片无法加载显示的样子

那些高星项目的 Star 列表，简直成了精准营销的“肉鸡池”。很多营销号和爬虫脚本疯狂抓取这些数据，然后给开发者发送骚扰邮件、广告推广。为了堵住这个口子，GitHub 决定把这扇门直接焊死。现在，你是谁、给谁点了 Star，除了你自己和项目维护者，谁也别想轻易通过 API 批量查到。

📉 受影响范围：star-history 首当其冲

GitHub 限制 Star 和 Watch 列表读取权限的应对示意

这个改动落地最直接的影响，就是那些依赖公开 API 获取 Star 数据的第三方工具。

最典型的就是 star-history.com。作为一个非常流行的开源项目推广辅助工具，它允许用户生成一张展示项目 Star 增长趋势的矢量图，很多开发者都会把它挂在 README 或者技术博客里。

由于该工具需要读取底层的 Star 数据来生成图表，随着 GitHub 权限的收紧，那些未授权的读取请求统统被拒之门外。结果就是，我们已经能看到大量历史图片无法加载，原本绚丽的增长曲线变成了尴尬的“图片裂开”图标。此外，仓库中原本指向 Stargazers 和 Watchers 页面的超链接，在 UI 层面上也被移除或取消了跳转，进一步强化了这种隔离。

💡 开发者该怎么办？替代方案与应对

既然 GitHub 为了隐私“铁了心”，我们作为普通使用者和开发者，也得见招拆招。虽然目前第三方工具（如 star-history）需要时间去适配官方的新认证机制，但我们并非无路可走。

1. 关注官方统计替代品

虽然列表看不到了，但 GitHub 并没有把所有门都关死。你仍然可以看到项目的 Star 总数和 Watch 总数。对于大多数只想证明“这项目很火”的场景来说，直接使用官方的 Shields.io 徽章可能是一个更简单、更稳定的方案。它只读取总数统计，不涉及具体用户列表，不受此次 API 变更影响。

2. 利用 GitHub 自带的 Insights

如果你是项目维护者，你可以进入仓库的 Insights -> Traffic 面板。虽然这里不直接给 Star 列表，但提供了访问量、克隆数等丰富的流量分析数据，足够你分析项目的健康度和流行趋势。

3. 等待第三方工具适配

像 star-history 这样的工具大概率不会就这么凉了。它们未来的迭代方向可能会转向要求用户提供 GitHub Personal Access Token (PAT) 进行鉴权。也就是说，如果你想生成图表，可能需要先手动授权一把。虽然多了个步骤，但为了数据安全和隐私，这可能是未来的常态。

4. 本地化解决方案

对于硬核玩家，如果你真的需要备份这些数据，现在只能依靠 GitHub 的官方导出功能（虽然不直接给 Star 列表，但有部分用户数据归档）或者通过爬虫模拟登录（但这可能触及合规红线，不推荐）来维护自己的私有数据库了。

写在最后

这次“断供”事件再次提醒我们，在享受免费、开放的 API 服务时，也要时刻做好被“收回”的准备。数据安全和隐私保护正成为大厂调整政策的核心理由。

对于普通看客，这一变动意味着更少的骚扰；对于工具开发者，这是一次被迫的升级迭代。至于那些裂开的图片，如果你不急着展示“辉煌战绩”，不妨先撤掉，等工具方更新了再说。

毕竟，写出好代码才是硬道理，Star 只是从锦上添花变成了真正的“私密收藏”。