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

网站建设基础知识：网站迁移应准备哪些记录？先列一份可核对的迁移档案

网站迁移前最该准备的是一份可核对的迁移档案，至少包含域名与DNS记录、服务器与数据库连接信息、程序与插件版本、页面与资源清单、重定向映射、备份文件位置、账号权限和验证结果。迁移不是把文件复制过去就结束，真正决定问题能否定位的，是迁移前是否记录了“原站是什么样”，迁移后能否逐项比对。

准备阶段：先记录原站现状，而不是先动文件

准备阶段的目标是留下可复核的基线。建议在迁移前完成以下记录，并保存在本地和云端各一份：

• 域名与DNS：域名注册商、DNS服务商、A记录、CNAME、MX、TXT等当前解析值，TTL剩余时间。
• 服务器信息：操作系统、Web服务器类型与版本、PHP或其他运行环境版本、站点根目录路径。
• 数据库：数据库类型与版本、库名、字符集、表前缀、当前大小、导出方式。
• 程序与扩展：CMS核心版本、主题版本、插件或模块清单及各自版本号。
• 账号与权限：后台管理员、数据库用户、FTP或SSH账号的归属和权限范围，密码不要写进明文文档，可记录保管位置。
• 备份：完整文件备份、数据库导出文件、备份时间、校验值或文件大小。

这一步最关键的是记录版本号和配置值，而不是只写“已备份”。例如只写“插件已备份”，迁移后出现白屏时无法判断是插件版本不兼容，还是文件缺失。记录成“插件A 3.2.1、插件B 1.8.0”，才能逐项比对。

实施阶段：迁移操作要留下变更记录

实施时每做一步都记下时间、操作内容、执行人和结果。常见记录项包括：

1. 新服务器的环境配置值，与原站逐项对照。
2. 文件和数据库的导入时间、导入方式、是否完整。
3. 配置文件中被修改的项，例如数据库连接、站点地址、缓存路径。
4. DNS修改的时间、修改前后的解析值。
5. 迁移过程中出现的报错原文，不要只写“报错”。

如果迁移后需要改站点地址，先确认原站记录中的地址写法，再决定改哪些位置。不同程序存放地址的位置不同，不能凭印象批量替换。此处应区分“可能原因”和“已经定位的原因”：页面打不开可能是DNS未生效，也可能是数据库连接失败，只有拿到解析结果和错误日志后才能下结论。

验证阶段：用清单逐项比对，而不是只看首页

验证阶段要拿准备阶段的记录逐项核对。建议至少检查：

• 首页和若干内页能否正常打开，状态码是否为200。
• 图片、CSS、JS等静态资源是否加载成功，路径是否仍指向旧域名。
• 表单提交、登录、搜索等动态功能是否可用。
• 数据库中的文章数、用户数、订单数等关键计数是否与原站一致。
• 旧链接是否按映射规则跳转到新地址，跳转状态码是否符合预期。
• HTTPS证书是否覆盖新域名，混合内容是否已处理。

假设原站有1000篇文章，迁移后后台只显示980篇，这就是可定位的差异：先查数据库导入是否完整，再查表前缀和字符集是否一致。若计数一致但页面404，则问题更可能在重定向规则或服务器配置，而不是数据丢失。

维护阶段：保留记录并设定观察期

迁移完成后不要立即删除旧站文件和旧备份。建议保留至少一个稳定周期，并记录：

• 旧服务器或旧空间的保留截止时间。
• DNS的TTL是否已调回常规值。
• 新站错误日志、访问日志的检查频率。
• 发现异常时的回滚步骤和回滚所需文件位置。

如果迁移后出现间歇性访问异常，先查DNS解析是否已全部生效，再查新服务器负载和程序日志。记录越完整，越能缩短从“现象”到“原因”的距离。

下一步可以做的，是把上述准备、实施、验证、维护四类记录整理成一张迁移检查表，每完成一项就填写实际值和核对结果，再开始正式迁移。