部署问题最容易让人直接重试命令。命令又失败之后，才发现自己没有回答一个基本问题：到底是哪一层失败了？

先拆成五层

我现在会按这个顺序检查：授权是否有效，Pages 项目是否存在，本地构建是否通过，资源是否上传完成，最后才看域名和 TLS。

这五层的好处是，每一层都有一个明确的证据。whoami 能证明授权，npm run build 能证明产物，部署列表能证明上传，而浏览器负责验证最终入口。

不要把本地回调当成 Cloudflare 故障

OAuth 登录会打开本地回调地址。如果浏览器回来了，但原来的进程已经退出，浏览器看到的就是“无法连接 localhost”。这和 Pages 本身还没有关系。

真正有用的做法是让登录进程保持运行，再完成一次授权回调。授权成功后再运行 whoami，确认账号和 Pages 写权限都在。

用稳定地址验证生产环境

哈希地址是某一次 deployment 的预览地址，适合定位版本；项目的 *.pages.dev 地址才是日常分享和验证生产内容的入口。两者不要混在一起判断。

下一步

下一次我想把构建和部署放进 Git 推送流程，减少手动步骤。但自动化之前，先把每一层的失败信号记录清楚，才不会把一条长命令变成黑盒。