是啊，吃什么

序幕：一个想自己更新的博客#

当了好几年的bangumi用户了，沉淀的信息总该有用武之地吧，于是把mizuki原有动画组件小改了一下，每天自动同步 Bangumi 数据（收藏、观看时间线，都来自 api.bgm.tv）。这直接抬高了选型门槛——不是「能托管静态页就行」，而是「能定时拉数据 + 免费 + 国内能访问」三件套。旧方案是 VPS 时代的遗物：crontab 半夜爬数据，rsync 推到服务器。能用，但像用牛车拉快递——每次更新还得记着它，哪天忘了，博客就停在昨天。

后宫选妃#

免费部署方式调查下来有七个——GitHub Pages、Cloudflare Pages、Netlify、Vercel、Render、EdgeOne Pages、Gitee Pages。

挨个查官方文档，查完一排排掉：

最后选了 Cloudflare Pages。不仅仅是因为免费档有 500 次构建/月、Git 集成原生、Deploy Hooks 官方文档白纸黑字写着「Schedule a CRON trigger」就是标准用法，还源自于对 CF 这家公司莫名的好感（好感度满了说是）。

小改了一下自动脚本，每次构建都会自动抓最新数据。所以「一天同步一次」等于「一天触发一次构建」。

由于这个博客原本是在 Linux 上改的，现在迁移到了 Windows，体检了一下，不然云端构建第一秒就炸：

1. Astro 7 要求 Node ≥22.12，CF 镜像默认 22.16.0，行，但要显式锁定，防镜像滚动更新偷偷换版本
2. 项目要 pnpm 11.5.3，CF 默认 10.11.1，也得锁
3. venv/（几百 MB 的 Python 虚拟环境）差点被 git add . 一起带进仓库——推上去就是灾难

一个晚上有四分之一时间在给「不存在的路径」和「没锁的版本」擦屁股，属于是给过去的自己还债。

一把仁之剑#

分支：给 Hermes 装 GitHub 能力，两条路——官方 MCP 服务器，或者 gh CLI。

算了一笔 token 账：MCP 的约 30 个工具每个都要常驻系统提示，6000~10000 token/轮白扣；gh 只多一个 terminal 工具，固定约 200 token。单次调用 MCP 还多花 500~1500 token。结论：装 gh。省 token 就是省钱，这题不难。

然后是 gh 认证，一波三折，两连跪：

跪一：浏览器授权成功了，但终端窗口被提前关掉，token 没写盘。浏览器说「已连接」，终端说「查无此人」——授权是持久了，凭据没落地，等于在白纸上签了名然后把纸扔了。

跪二：重跑，这次直接超时。gh 是 Go 写的，不读 Windows 系统代理，直连 GitHub 被墙。错误信息很诚实：dial tcp 20.205.243.166:443 连不上。解法一句话：HTTPS_PROXY=http://127.0.0.1:10808 gh auth login --web。

意外收获：排查 MCP 文档时发现 Hermes 原生支持 OAuth 2.1（PKCE + 动态注册 + 自动刷新 + 落盘持久化），实现都在源码里躺着，文档愣是没写。之前差点因为「文档没提」就断定「不支持」。

什么叫异步我请问了

海的那边，是自由#

前段日子，Bangumi 刚被 GFW 拿下了，我担心云端直连 Bangumi 到底行不行，用脚本测了一下结果 next.bgm.tv 200 in 0.15s——GitHub runner 在境外直连比本地走代理快 30 倍。「国内访问不了」的顾虑当场击毙

仓库侧齐活了：源码 + 原始数据 + 定时 workflow + secret，全部就位。万事俱备，只欠一个 Cloudflare。

一把义之剑#

坑一：桌面 app 的 agent 是非交互环境，OAuth 必然报 OAuthNonInteractiveError 并搁浅。正解是外部终端跑 hermes mcp login cloudflare——相当于钥匙胚得在车床上打，不能在餐桌上敲。

坑二（灵异事件）：授权页开了 4 个标签页，点哪个都失败。排查半天，根因是 mcp SDK 在 401 时会自动重连，每次重连开个新标签页，每个标签页的 GET 都会覆盖同一个 __Host-CSRF_TOKEN cookie——旧标签页提交的 token 和当前 cookie 对不上，CF 回 error=invalid_request。

人话：你在过期的彩票上刮奖，中奖了也不算数，因为奖池已经换了一轮。

竟然不许#

工具到手，开始建项目。兜兜转转找半天，终于在cf的权限管理里面找到了pages给write权限勾上了。每次到cf的界面，就感觉跟回家了一样舒服啊（棒读）。

噔噔咚——8000011: Git installation issue。任督二脉没打通：CF 要读 GitHub 仓库靠的是 Cloudflare Workers & Pages 这个 GitHub App——根本没装。CF OAuth 只证明「CF 认识你」，GitHub App 才证明「GitHub 愿意给 CF 看仓库」。装 App 时授权范围只选这一个仓库，多一个仓库都是埋雷。

项目建起来后手动触发首次构建，流水线跑完：

1
初始化 → 拉代码 → 构建（前段时间抓的timeline + 云端抓增量收藏 + astro build + pagefind 索引）
2
→ 部署 → 357 个文件全球分发

Success: Your site was deployed!——ohhhhhhhhhh！！！

回头看，一共是五步：

1. 选型：七选一，定时能力是硬门槛
2. 打通 GitHub：gh 认证两连跪，代理环境变量救场
3. 仓库改造：原始数据入库、生成物现做，实测云端连通性
4. 打通 CF：OAuth 多标签页 csrf 打怪 + 双授权链排查
5. 部署上线：357 文件，一次成功

虽然说是走通了部署流程，但是博客还没有正式的完全改完，里面还有很多地方需要精装修。