先设定场景：一个即将上线的亚星网站
假设你所在的团队准备上线一个新的亚星网站，域名已解析，页面已部署，内容也基本填完。上线窗口定在两天后的晚上，参与的人包括一名前端、一名后端和一名负责内容运营的同事。没有人做过完整的上线前核对，大家凭经验判断“应该没问题”。
这个场景里没有客户名，也没有具体业绩数字，只有约束和待确认项。本文把它当作一次场景推演，把亚星网站在上线前需要核对的内容整理成清单，方便你对着自己的项目逐条勾选。
锁定约束：时间、人员与验收口径
在动手核对之前，先把三类约束写下来，否则清单会失控。
- 时间约束：上线窗口只有两个小时，回滚窗口更短，核对必须在窗口前完成。
- 人员约束：谁有权改配置，谁只负责确认，谁在出问题时拍板，需要提前写明。
- 验收口径：什么叫“上线成功”，是首页可访问，还是核心路径可走通，需要统一说法。
- 环境约束：测试环境与生产环境的差异是否已知，差异项是否已列成清单。
- 内容约束：哪些页面必须上线，哪些可以延后，避免上线时临时补内容。
约束写清楚之后，核对才有边界。否则清单会越列越长，最后变成一份没人愿意执行的文档。
推演核对：按顺序走一遍自检清单
下面按实际操作顺序推演一遍。每一步都对应可观察的现象，而不是主观判断。
- 核对域名解析：确认解析指向的目标与预期一致，避免上线后仍指向旧环境。
- 核对基础访问：从多个网络环境打开首页，观察是否都能正常返回。
- 核对核心路径：走一遍注册、登录、提交等关键动作，确认没有中断。
- 核对静态资源：检查样式、脚本、图片是否加载完整，避免页面错位。
- 核对跳转规则：确认旧链接、短链、外链的跳转行为符合预期。
- 核对表单提交：提交一次测试数据，确认后端能收到并给出反馈。
- 核对错误页面：访问一个不存在的地址，确认错误提示清晰可用。
- 核对移动端显示：在手机尺寸下检查布局和可点击区域。
- 核对内容完整性：确认必上页面没有空白、占位文字或未替换的示例。
- 核对回滚方案：确认回滚步骤可执行，且有人知道在哪一步执行。
走完这一轮，把不通过的项目单独记下来。清单的价值不在于全部打勾，而在于把“不确定”变成“已确认”或“待处理”。
边界分支：几种常见异常该怎么处理
推演过程中总会遇到分支。下面用三个小标题拆开，方便对照自己的情况。
分支一：访问正常但部分资源加载失败
先区分是路径问题还是权限问题。检查资源地址是否写死、是否跨域、是否被缓存。不要急着改代码，先确认现象是否可稳定复现。
分支二：核心路径在测试环境通过、生产环境失败
优先对比两套环境的配置差异，包括接口地址、密钥、依赖版本。把差异项列出来，逐项确认，而不是凭印象猜测。
分支三：上线窗口临近但清单未完成
此时应做取舍：把未完成项分成“必须上线前完成”和“可上线后补齐”。明确谁在什么时候补，避免上线后无人跟进。
决策记录：把清单结果转成下一步动作
推演结束时，不要只留下一份打勾的表。把结果转成三类动作：立即修复、上线后跟进、暂不处理。每类动作写清负责人和时间点。 网站优化
- 立即修复：影响核心路径的问题，必须在窗口前解决。
- 上线后跟进：不影响首次访问的优化项，排入后续计划。
- 暂不处理：已确认无影响或成本过高的项目，记录原因即可。
- 复核对：上线后按同一份清单再走一遍，确认没有回归。
这份清单可以复用到下一次网站建设或网站优化迭代中。场景会变，但约束、核对、分支和决策这四步不会变。