不少线上事故的原因并不复杂：本地调试用的配置忘了改回去、临时注释掉的缓存开关没有恢复、为了排查问题加的白名单一直留在线上。这些问题通常不会立刻报错，而是过几天有人反馈“这个页面怎么不对”，才被翻出来。
把发布从“记得就好”变成一张固定清单，是站点运营里投入产出比较高的一件事。下面的清单不复杂，中小站点可以直接抄下来用。
先给发布分级，不要每次都全量检查
如果每次改一个错别字也走完整流程，清单很快就会没人执行。更现实的做法是按影响面分三档：
- 轻量改动：文案修改、图片替换、单篇文章发布。只需要确认发布环境和回滚方式。
- 常规发布：模板调整、栏目结构变化、新增功能模块。需要走完整清单。
- 高风险发布：域名、证书、服务器迁移、数据库结构变更、缓存或 CDN 策略调整。需要额外安排观察时间和明确的回滚决策人。
发布前：配置与环境
- 调试开关是否全部关闭？包括详细的错误输出、SQL 慢查询打印、模板调试信息、前端 sourcemap 是否对外可访问。
- 配置文件里的域名、接口地址、回调地址是否指向正式环境，而不是测试域名或内网 IP。
- 临时加的访问白名单、绕过登录的开关、测试账号是否清理干净。
- 新增的第三方密钥、推送渠道、统计代码是否换成正式账号。
- robots 相关设置是否有变化。如果这次发布了新栏目，确认它应该被访问还是暂时不对外。
发布前：数据与回滚
- 这次改动是否涉及数据库结构？如果有，确认变更脚本可以重复执行，并且知道怎么撤销。
- 发布前是否有一个可用的备份，而且验证过能恢复。只生成备份文件、从不测试恢复，是常见的心理安慰。
- 回滚方案是否具体到操作步骤？是切回上一个版本、还原配置，还是回滚数据库。含糊的“有问题就回滚”在紧急时刻帮不上忙。
- 参与发布的人是否都知道谁有权决定回滚，避免事发时互相等对方拍板。
发布中：顺序和节奏
- 先发布不依赖新数据的部分，再发布依赖部分。涉及前端和后端同时改动时，先让后端兼容旧前端。
- 一次只改一个变量。同时上线模板改版和缓存策略调整，出问题时很难判断是哪一个引起的。
- 如果站点有多个节点，采用逐台发布，确认第一台正常后再继续。
- 发布完成后立刻手动访问几个关键页面，包括首页、一个栏目页、一篇详情页和一个需要登录或提交的页面。
发布后：第一小时看什么
- 服务器错误日志里是否出现新的报错类型，而不是只看错误总数。
- 首屏响应时间和错误率相比发布前是否明显变化。小幅波动正常，翻倍就值得查。
- 是否有异常的 404 或 500 集中在某个路径上，这通常指向漏传的文件或写错的路径。
- 抓取行为是否正常。如果发布后短时间内大量抓取集中在某个无效路径上，可能是新生成的链接有问题。
- 表单、搜索、登录这类交互入口是否真的能提交成功，而不是只看页面能打开。
把清单落到流程里
清单写了不执行等于没写。比较有效的做法是把它挂在发布入口旁边，比如提交发布申请时附上一个勾选表，没勾完就不进入发布环节。清单本身也要定期复盘：每次出现问题后，问一句“如果清单里多加哪一项，这次就能提前发现”，然后加进去；长期没人踩的条目，可以考虑删掉，保持清单简短才有人愿意用。
发布流程的目标不是让发布变慢，而是让可预期的问题在发布前暴露，让不可预期的问题在发布后能快速回退。清单越短、越具体，越可能被真正执行。