网站制作教程：网站迁移应准备哪些记录？先列一份可执行清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /24688a327d9a.html
📄
网站制作教程：网站迁移应准备哪些记录？先列一份可执行清单
网站迁移前最该准备的记录，是一份能让你在出问题时回退、核对、交接的迁移档案。它至少要包含四类内容：迁移前的原始状态记录、迁移中的操作记录、迁移后的验证记录，以及上线后的维护记录。对时间和人手有限的团队，优先做前两类，因为它们决定了你能不能安全回退。
准备阶段：先把“迁移前长什么样”记下来
迁移最容易出问题的环节不是上传文件，而是没人说得清原来是什么状态。准备阶段要记录的是可核对的事实，不是感觉。
- 域名与解析记录：当前使用的 DNS 服务商、A 记录、CNAME 记录、MX 记录、TXT 记录的完整值。截图或导出区域文件，不要只记“指向某台服务器”。
- 服务器与运行环境：操作系统版本、Web 服务器类型与版本、PHP 或 Node 等运行时版本、数据库类型与版本。这些决定了新环境能否直接跑起来。
- 网站文件与数据库：程序根目录路径、数据库名与表前缀、附件或上传目录位置。记录备份文件的生成时间和存放位置，并确认备份能解压、能导入。
- 账号与权限：域名注册商账号、DNS 管理账号、服务器登录方式、数据库账号、后台管理员账号。记录谁持有、谁能操作，避免迁移中卡在“找不到密码”。
- 外部依赖：CDN、对象存储、邮件推送、支付回调、统计代码、第三方接口。记录每一项是在哪里配置的，迁移后要逐项改指向。
如果人手紧张，这一步至少完成域名解析记录和数据库备份两项。缺少解析记录，回退时无法快速恢复；缺少可用的数据库备份，迁移失败就没有退路。
实施阶段：记录每一步改了什么
实施阶段的核心是让操作可追溯。建议按时间顺序记一条操作日志，每条包含时间、操作人、操作对象、改前值、改后值。例如：
14:20 修改 DNS A 记录，原 203.0.113.10 改为 198.51.100.24
假设性的例子，用于说明记录格式。实际操作时把 IP 换成你自己的真实值。日志里还要记下每次操作后的即时现象，比如“解析生效后首页可打开，后台登录报数据库连接错误”。现象和原因要分开写：报数据库错误可能是配置未更新，也可能是数据库未导入，不要当场断定只有一个原因。
同时记录迁移过程中的临时决定，例如某个插件暂时停用、某条旧链接暂不重定向。这些决定在验证阶段会被重新检查。
验证阶段：用清单逐项确认，而不是凭感觉
迁移完成后，按准备阶段记录的内容反向核对，这是最省时间的验证方式。
- 打开首页、栏目页、内容页各若干条，确认能正常返回内容。
- 登录后台，确认账号可用、能发布或编辑一条测试内容。
- 检查表单提交、搜索、评论等交互功能是否正常。
- 核对邮件收发、支付回调、第三方接口是否仍指向正确地址。
- 用原解析记录对比当前解析，确认没有遗漏的 MX 或 TXT 记录。
- 抽查旧链接是否仍可访问，需要重定向的地址是否已配置。
每一项记录“通过”或“不通过”，不通过的写明现象。验证不通过时，先判断是配置问题还是数据问题，再决定修配置还是回退。回退依据就是你准备阶段保存的解析记录和备份文件。
维护阶段：留下能交接的记录
迁移结束不等于记录结束。把最终生效的解析值、服务器信息、账号归属、备份位置整理成一份现状说明，注明更新日期。后续换人接手或再次迁移时，这份说明就是起点。
维护记录还应包括监控与告警方式：谁在什么条件下会收到通知，发现异常后第一步查什么。时间和人手有限时，至少保证域名到期时间、证书到期时间、备份周期三项有人负责查看。
下一步建议：打开你的域名解析管理页面，把当前所有记录导出或逐条抄录，同时确认最近一次数据库备份可以成功导入。这两件事做完，迁移的风险就已经降下一大截。
