📍 WDQWDWQD987AAAAA:216.73.216.187
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b43ff8d52e76.html
📄

网站开发中，网站迁移应准备哪些记录，按交付倒推的资料清单

网站迁移要准备的记录，核心是四类：迁移前的现状快照、迁移中的操作日志、迁移后的验证结果、以及责任与回滚约定。判断标准很简单——如果迁移后出现排名波动、页面打不开、表单收不到信、支付异常，你能不能用这些记录在半小时内定位到是哪一步、哪台机器、哪条规则造成的。记录不是给上级看的文档，而是排障时的证据链。

迁移前必须留存的现状快照

迁移最容易出问题的地方，是没人说得清“原来是什么样”。所以第一步是把旧站的运行状态固定下来，作为后续比对的基线。

• URL 清单：从站点地图、服务器访问日志、数据库文章表三处交叉导出，合并去重后得到完整 URL 列表。数量对不上，说明有页面只存在于某一处。
• 状态码与跳转关系：用抓取工具跑一遍全站，记录每个 URL 返回的状态码和最终落点。特别标记 301、302 链和跳转环。
• 页面关键元素：标题、描述、canonical、hreflang、结构化数据。这些是迁移后最容易被模板改掉的部分。
• DNS 与证书信息：当前解析记录、TTL 值、证书签发机构和到期时间。TTL 若设得很长，迁移当天的生效等待时间要提前算进去。
• 服务端配置：伪静态规则、重定向规则、缓存策略、CDN 回源设置。这些往往不在代码仓库里，只在服务器上。

建议把这份快照存成可版本控制的文本文件，而不是截图。截图无法做批量比对。

迁移过程中的操作日志要记到什么颗粒度

操作日志的作用是回答“谁在什么时候改了什么”。粒度太粗等于没记，太细没人愿意写。一个可执行的标准是：每一条记录都能对应到一个可回滚的动作。

1. 时间点精确到分钟，并注明时区，避免跨团队协作时对不上。
2. 操作人写实际执行者，不写团队名。
3. 动作描述包含对象和参数，例如“将 www 的 A 记录从 1.2.3.4 改为 5.6.7.8，TTL 由 3600 调为 300”。
4. 结果写实际观察到的现象，不写预期，例如“解析生效，新 IP 返回 200”。

数据库导出、文件同步、配置修改、DNS 切换、证书更新，这几类动作必须逐条记录。假设一次迁移中数据库字符集从 utf8 改成 utf8mb4，日志里没写，迁移后部分中文页面出现乱码，排查方向就会跑偏到模板编码上。

迁移后验证哪些项目才算完成

验证不是打开首页看一眼。要按“能否被访问、能否被正确理解、能否完成业务动作”三层来查。

• 可访问性：旧 URL 是否全部有响应，状态码是否为 200 或预期的 301，是否存在 404 和 5xx。
• 一致性：新站页面数量、标题、canonical 是否与迁移前快照一致，差异项要逐条说明原因。
• 业务功能：表单提交、登录、搜索、支付、文件下载。这些要实际走一遍流程，而不是只看页面渲染。
• 性能与抓取：首字节时间、页面体积、robots.txt 是否误屏蔽、站点地图是否可访问。

把验证结果写成“项目—预期—实测—结论”的表格。结论只有通过或不通过，不写“基本正常”。一项不通过就要判断是阻断上线还是可以带病观察，这个判断本身也要记录。

责任划分与回滚方案怎么落到纸面

迁移涉及开发、运维、内容、市场多方。记录里要明确每一项的负责人和决策人，尤其是“谁有权决定回滚”。

回滚方案要包含触发条件、执行步骤和预计耗时。触发条件写具体数值，例如“新站首页连续 5 分钟返回 5xx”或“核心表单提交成功率低于迁移前水平”。执行步骤写清 DNS 改回哪个值、数据库用哪份备份、静态资源从哪个目录恢复。预计耗时要在迁移窗口内留出余量。

如果迁移后需要观察一段时间，还应约定观察期的检查频率和记录方式，例如每天固定时间抓取一轮关键 URL 并记录状态码，形成时间序列，便于判断问题是持续性的还是偶发的。

下一步可以做的具体动作：把上面四类记录整理成一份迁移检查表，在迁移开始前逐项确认是否已有对应记录。任何一项拿不出记录，就先补齐再动手，因为迁移开始后补记的成本会高得多。