荆门网站制作：网站迁移应准备哪些记录
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /eb61d7d53841.html
📄
荆门网站制作：网站迁移应准备哪些记录
网站迁移前应准备一份可交付的迁移记录包，至少包含原站资产清单、环境与依赖、域名与解析、数据库与内容、重定向规则、验证结果和回滚方案。它的作用不是留档好看，而是让接手的人在不问你任何问题的情况下，能判断迁移是否完整、出错后能否退回。多人协作时，记录缺失往往就是返工的根源。
先观察：迁移前必须盘清哪些对象
迁移不是复制几个文件，而是搬迁一整套运行关系。开始动手前，把下面几类对象逐一列成表，每项标注负责人和确认状态。
- 文件与代码：站点根目录、上传目录、主题或模板、自定义脚本、静态资源，记录各自体积和最后修改时间。
- 运行环境：Web 服务器类型与版本、程序语言版本、必需的扩展模块、计划任务或定时脚本。
- 数据：数据库名称、字符集、表前缀、需要保留的附件与日志，以及导出文件的校验值。
- 域名与解析：当前 DNS 服务商、A 记录与 CNAME 记录、TTL 值、是否启用 CDN 或第三方防护。
- 证书与账号：SSL 证书类型与到期时间、需要交接的管理账号清单（只记账号归属，不记明文密码）。
- 外部依赖：短信、支付、统计、地图等第三方接口的调用方配置，记录在哪一侧需要改。
判断标准很简单：如果某台新服务器只拿到这份表，能否在不动原站的前提下把站点跑起来。跑不起来，说明清单缺项。
再判断：哪些记录决定迁移能否验收
记录分两类，一类是“搬什么”，一类是“搬对没有”。前者是资产清单，后者是验收依据，缺了后者，迁移完只能靠肉眼感觉。
验收依据至少包括：迁移前抓取的页面地址列表及对应状态码、核心页面的标题与关键内容快照、表单提交与登录等交互路径的可复现步骤、数据库记录条数。以页面地址为例，迁移前用爬取工具导出全站 URL 并保存为文件，迁移后对新站同样导出一次，两者对比：原地址返回 200 的，新站应返回 200 或 301；原地址返回 404 的，新站不应突然变成 200。出现差异就逐条记录，而不是笼统地说“基本正常”。
这里要区分“可能原因”和“已定位原因”。比如迁移后某栏目打不开，可能是文件未同步、可能是伪静态规则未迁移、也可能是数据库连接配置错误，三者现象相似。记录时应写成“现象 + 已排除项 + 待验证项”，不要直接下结论，否则接手人会沿着错误方向排查。
处理：记录包按什么结构交付
建议用一个总目录加若干子文件，结构固定，方便多人同时填写。
- 迁移说明：迁移原因、计划时间窗口、影响范围、负责人与联系方式归属。
- 资产清单：文件、数据库、账号、外部依赖四张表，每行含名称、位置、负责人、状态。
- 环境配置：新服务器需要安装的软件与版本，附一份可执行的初始化步骤。
- 重定向表：原地址到新地址的对应关系，逐行列出，注明是 301 还是 302 及适用条件。
- 验证记录：按检查项逐条填写结果，通过写通过，不通过写现象与处理人。
- 回滚方案：什么条件下回滚、回滚需要改哪几项、预计耗时、谁有权决定。
重定向表是返工高发区。假设原站有 /old-page.html，新站对应 /new-page/，就应写清这一行；如果新站没有对应内容，要明确是跳首页还是返回 410，不能留空让执行人自己猜。适用条件是：地址结构发生变化时必须逐条映射；结构完全不变时可以只做抽样核对，但仍要保留抽样清单。
复查：迁移完成后核对哪些项
复查不是再看一遍页面好不好看，而是拿迁移前的记录逐项比对。
- 页面可达性：抽样访问首页、栏目页、详情页、搜索页，确认状态码与迁移前记录一致。
- 数据完整性：比对数据库表记录数、附件数量、最新几条内容的发布时间。
- 功能可用性：按迁移前写好的交互步骤走一遍，重点测登录、提交、支付回调等跨系统环节。
- 解析与证书：确认域名解析已指向新环境，证书链完整，访问不出现混合内容警告。
- 旧地址处理：随机抽取重定向表中的若干行实际访问，确认跳转目标与状态码符合预期。
发现不一致时，先判断是记录本身写错了，还是迁移执行漏了。如果是记录写错，当场修正记录并注明修正人；如果是执行漏项，补做后重新验证该条，不要只口头说明。多人协作下，口头确认最容易在交接时丢失。
下一步可以做的，是把上面六类记录整理成一份空白模板，让每个参与者在迁移开始前先填“资产清单”和“验证记录”两栏，填不出来的部分就是还没盘清的部分。
