发布检查 · 实用指南
小项目发布与回滚检查：上线前想好退路
发布不仅是把文件传上去。你还需要知道这次改了什么、怎样确认访客能使用，以及发现故障后如何恢复服务。
先定义这一次发布
用一个虚构项目举例：个人作品集网站准备增加三个案例页，并更新联系表单。把这两项写进发布记录，给本次产物一个可辨认的编号，例如“作品集第二版”。保存当前线上版本、发布配置和恢复入口，确认自己仍有权限使用它们。备份存在不等于能够恢复，最好在预览环境走一遍恢复步骤。
发布前，完成四项检查
- 检查内容：逐页检查标题、图片、链接和下载文件；移除示例联系方式与未完成承诺。确认将要上传的目录就是本次产物。
- 走核心流程：从首页进入案例，再返回首页；用测试内容提交表单，确认约定的接收端出现对应记录。只看到成功提示还不够。
- 覆盖失败情形：空字段、格式错误和提交失败时，用户应得到清楚提示；使用窄屏和键盘检查重要入口能否操作。
- 明确停止条件：例如首页无法打开、联系表单无法接收、主要导航失效时恢复旧版。说明由谁观察、在哪里恢复，避免出问题后临时寻找入口。
发布后，检查真实入口
部署完成后，从正式域名重新进入网站，核对页面版本和关键内容。不要只查看本地页面或平台的完成提示。按核心流程再走一次，记录检查时间、使用的地址、预期与实际结果。若页面仍显示旧内容，先确认访问地址、资源路径和缓存情况，避免在原因不明时反复覆盖文件。
错误示范与改进
错误示范：“上传成功，首页能打开，发布完成。有问题再修。”
改进为：“本次新增三个案例并调整表单。正式域名下逐个访问案例，检查图片与返回入口，再提交一条可识别的测试记录并核对接收端。若关键流程失败，使用已保存的上一版产物恢复，恢复后重复相同检查。”这是一份待执行的检查方案，不表示这些检查已经通过。
回滚也要验证结果
触发停止条件时，暂停继续发布，保留必要的错误截图和时间信息，然后恢复已确认的旧版。再次访问正式域名，核对版本与核心流程，记录哪些问题已消失、哪些仍存在。只有旧文件重新上传，不能说明故障已经恢复。对于正在进行的用户操作，也要说明是否需要重新尝试。
数据变化需要单独安排
如果发布包含数据库结构、支付配置或外部服务调整，恢复网页文件可能无法撤销这些变化。应分别列出兼容要求、备份范围和恢复办法，尤其不要直接覆盖发布后新产生的业务数据。拿不准时，应先在隔离环境验证，并请熟悉该系统的人审查方案。
这套方法的适用边界
这份清单适合个人网站、静态页面和低复杂度小项目。多人协作、高流量或关键业务系统还需要更完整的监控、权限与事故处理流程。每次发布留下简短而真实的记录，比填写一大份无人核对的“全部通过”更有帮助。