14. 完成一次有监督的部署

本地这台机器，是所有假设最舒适的温床：网络稳定、设备就一台、操作者就是作者本人。部署把工具推到公网之后，这些假设一次全部失效，换成各种设备、各种网络、各种陌生的使用方式。这一章做一次有人看守的部署，把这些失效尽早暴露出来。

本地可用为什么不够

本地测「能用」，测的是「在这台机器、这个网络、这个人手里能用」。线上要面对的是别人的旧手机、时好时坏的网络、第一次见到这个工具的人。这三样每一样都可能戳破一个在本地永远不会暴露的假设。有监督的部署，就是在真实条件下把这些假设过一遍，而不是等使用者替作者踩雷。

一次有监督的部署

托管平台怎么选，本身就是一次需要裁决的判断。Cloudflare Pages、Vercel 这类海外平台功能成熟、文档齐全，但多方实测和社区反馈都提到，它们在中国大陆的访问速度和稳定性并不总能保证，偶发的连接失败或者需要额外加速手段并不罕见。这本书自己的站点用的正是 Cloudflare Pages，如果从中国大陆访问偶尔卡顿，本身就是这条判断的一次实证。

腾讯云 EdgeOne Pages 是另一个可考虑的选项：同样支持连接 Git 仓库、自动构建部署，走的是国内 CDN 节点，官方定位就是解决海外平台在国内访问慢的问题，注册后的免费额度足够跑通这一章的练习。

两类平台代表两种取舍：选生态更成熟的海外平台，还是选国内访问更稳的平台。答案取决于目标使用者主要在哪访问，跟哪个平台更知名无关。具体平台的额度和条款会变，到官网核对当前信息，这里只走通用流程：

1. 到选定的平台官网注册账号，按官方文档把项目仓库连接上（通常是授权访问 GitHub 或 GitLab），确认构建命令和输出目录，触发一次部署，拿到一个公网地址。连接时只授权这个平台完成部署所必需的最小权限，呼应上一章「权限只给到刚好够用」那条检查。上一章表格里另一条遗留项，补一个使用者能看到的错误提示，也在这一步之前一并修完，不要带着已知空白上线。

2. 用一台确定处于中国大陆网络环境的设备打开这个线上地址，把第 5 章那几条验收样例逐条跑一遍，确认线上行为和本地一致，也确认这个地址真的打得开。文档说的「可访问」和实际能访问，是两件需要分别核验的事。

3. 主动演练一次回退：把线上退回上一个版本，确认退得回去，再恢复。回退能力要在真出事之前先验证过。

4. 把线上地址交给三名使用者，按第 11 章的规矩：只观察和记录，不替工具解释。

三名使用者比一名能暴露更多，因为设备、习惯和输入各不相同。记录他们各自卡在哪、输入了什么、看到什么。

只修一轮

观察完之后，会攒下一批问题。这里立一条限制：只根据观察到的问题，完成一轮修订。

这一章的目标是完成一次有监督的部署，不是把产品做完善。一旦开始顺便再加个功能、再优化个体验，部署章就会滑成没有尽头的产品开发。挑出这一轮观察里最该修的，按第二幕的闭环（写验收条件、加测试、改绿、看 Diff）修完这一轮，重新部署，这一章就收尾。剩下的问题记进清单，留给以后。

留下什么产物

这一章的产物是一张部署记录卡，把这次部署定格下来：

项目	内容
线上地址	部署后拿到的公网地址
部署时间	这次部署完成的时间
版本标识	对应的提交或版本号
回退记录	演练回退的结果，退得回去
反馈摘要	三名使用者暴露的主要问题，以及这一轮修了哪条

这张卡的作用是让「这次上线做过什么」可追溯：出了新问题，能对照它判断是这次改的还是本来就有的。

这一章可以对 AI 说的一句话

我要把这个静态项目部署到一个国内可访问的托管平台。请按「连接仓库、触发部署、验证线上、演练回退」列出步骤，并在每一步标出哪些动作不可逆、需要我先确认。先不要替我执行部署。