本地打开 index.html 一切正常，是很多项目最快乐的时刻。之后要回答的是一串并不浪漫的问题：谁来托管、怎么更新、域名从哪来、出错怎么退回去。

三条常见通道

第一种是纯静态托管，把构建产物上传到对象存储或静态空间，配好 CDN 与 HTTPS，最省心，代价是发布流程要自己维护。第二种是连接代码仓库的构建平台，推送即构建，天然带预览环境与回滚，但平台会接管一部分构建约定。第三种是边缘运行时，让请求先经过一段代码再决定返回什么，适合需要按路径生成页面、做重定向或注入响应头的场景。

三者不是替代关系。内容型站点常常是构建产物加一层很薄的边缘逻辑：HTML 静态化保证首屏与可索引，边缘层处理路由、缓存头和兜底页。

权限边界比命令更重要

用命令行发布时，需要一枚有写权限的凭据；用平台接口发布时，同样要面对令牌能做什么。最小权限原则在这里很具体：只给目标项目写权限，不给账户级全权限；令牌设置有效期；不要把凭据写进仓库。很多事故不是因为技术选错，而是因为一枚权限过大的令牌被提交到了公开仓库。

另一个现实约束是：不同发布方式对凭据的要求不一样。有的接口需要专用的一次性上传令牌，账户级令牌反而不被接受；有的平台要求先在网页侧完成仓库授权，接口才能连接。上线前先花十分钟验证发布通道，比写完整个站点再发现传不上去划算。

一份可验证的上线清单

生产域名返回 200；带 www 与不带 www 的行为一致；文章深链直接打开正常；刷新深链不落到 404；静态资源带正确的缓存头；404 页可用；HTTPS 证书有效；能找到上一次部署并回滚。逐条点一遍，比看起来能打开可靠得多。

最后，把发布方式写进项目 README。半年后想加一篇文章时，最费时间的往往不是写文章，而是重新想起当初是怎么把它发出去的。