网站迁移前最该准备的记录,不是“备份完就完事”,而是一份让接手的人能独立判断、回滚和验收的交付包。多人协作时,建议把记录分成六类:环境与账号、数据与文件、域名与解析、配置与依赖、迁移操作日志、验收与回滚。每一项都写清“要查什么、怎么查、结果说明什么”,这样即使换人操作,也能减少返工。
要查的是源站和目标站的操作系统、Web 服务器、数据库版本、运行环境版本,以及各层账号的归属。怎么查:在服务器上执行版本查询命令,在数据库里查看版本信息,把结果贴进交付文档。
uname -a,结果用于判断目标环境是否兼容。nginx -v 或 apachectl -v,结果说明重写规则和模块是否需要调整。mysql --version 或对应数据库的版本命令,结果决定导出导入参数。判断结果:如果目标环境版本低于源站,先做兼容性验证,不要直接迁移。适用条件:多人协作时,账号必须可交接,不能只留在某个人手里。
要查的是数据库、上传目录、主题或模板、插件或扩展、配置文件、定时任务、日志目录分别在哪里,体积多大。怎么查:用目录统计和数据库表清单逐项核对。
判断结果:如果上传目录体积远大于数据库,先确认是否包含可再生成的缩略图或缓存。适用条件:任何有用户上传内容的站点都应逐项核对,而不是只迁数据库。
要查的是域名注册信息、DNS 解析记录、TTL、证书覆盖域名、邮件相关记录。怎么查:在 DNS 管理后台导出记录,在域名注册商处核对到期时间。
判断结果:TTL 较长时,切换前先调低,减少回滚等待时间。适用条件:涉及邮件、CDN 或多子域名的站点,必须单独列出,不要和主站解析混在一起。
要查的是伪静态规则、重定向规则、环境变量、PHP 或运行环境扩展、依赖包版本、外部服务接口。怎么查:对照源站配置文件逐项记录,再在目标环境逐项验证。
判断结果:如果目标环境缺少某个扩展,页面可能报错或功能失效,这属于可能原因,需实际验证后再定位。适用条件:使用框架或 CMS 的站点,依赖记录尤其重要。
要查的是每一步操作的时间、执行人、命令或操作内容、结果。怎么查:边操作边记录,不要事后补。验收时按清单逐项打勾。
判断结果:验收项全部通过才算迁移完成;只要有一项失败,先判断是配置问题还是数据问题,再决定继续修复还是回滚。适用条件:多人协作时,操作日志和验收记录就是交付凭证,能显著减少“谁改的、改了什么”的返工。
下一步:把上面六类记录整理成一份迁移交付文档,指定一人维护、一人复核,并在正式切换前做一次完整演练,确认回滚路径可用。