拆掉 GitHub API：一次本地优先的架构决策

事故现场

个人门户 v1 有个很”极客”的设计：构建时请求 GitHub API，把用户的仓库、star 数自动同步进页面。数据永远新鲜，零手工维护。

直到某天，api.github.com/users/min09577 开始返回 404——账号被平台风控标记了。构建还在跑，数据源没了，页面上的作品列表变成了降级的示例数据。

复盘：这个设计的三个隐含假设

1. 假设账号永远可访问——错误。平台风控、误判、区域问题，任何一条都能让 404 从天而降。
2. 假设构建机器网络可靠——脆弱。构建产物居然依赖一次网络请求的成功与否，这在工程上是不可接受的。
3. 假设数据量配得上实时性——错误。一个作品列表几个月才变一次，为它引入运行时依赖，收益和风险完全不成比例。

决策：数据本地化

把数据源拆掉，仓库与统计数字全部收进 config.ts 本地维护，构建时零外部请求。三个直接收益：

• 确定性：npm run build 的结果只取决于仓库内容，不取决于 GitHub 的心情
• 速度：构建少了网络往返，CI 上更快更稳
• 可审查：页面上的每个数字都能在代码库里找到出处

但要留好重连的插口

本地化不等于永久放弃自动化。原始的 getGitHubData() 接口签名原样保留，将来账号恢复，把 fetch 逻辑装回去，上层组件一行不用改。

这是这次复盘最重要的经验：拆依赖的时候，把接口留在原地。数据源可以换，契约不能换。

一条判断标准

以后凡是”构建时请求外部服务”的想法，先过一遍这个筛子：

这份数据的变化频率，配得上引入的失效风险吗？

变化按月计的内容——不配。老老实实进代码库，让 git 替你管理它的历史。