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

昭通网站制作 - 网站迁移应准备哪些记录

网站迁移前应准备的记录，核心是三类：原站资产清单、环境与账号凭证、迁移过程中的变更日志。缺少任何一类，迁移后就可能出现页面打不开、数据对不上、无法回滚却查不到原因的情况。下面按第一次做迁移的视角，说明每类记录具体要记什么、怎么记、记到什么程度算合格。

第一类记录：原站资产与内容清单

迁移不是把文件复制过去就结束，先要把“原站有什么”写清楚。这份清单是迁移后逐项核对的依据。

• 页面清单：记录所有需要保留的页面路径，例如首页、栏目页、内容页、专题页。可以用站点地图或爬取工具导出一份 URL 列表，逐条标注是否保留、是否合并、是否删除。
• 文件与目录结构：记录根目录下有哪些文件夹、哪些是程序文件、哪些是上传的图片和附件。附件目录往往体积最大，单独列出来。
• 数据库信息：数据库名称、字符集、数据表前缀、大致数据量。不要只记“有个数据库”，要记到能据此还原的程度。
• 内容对应关系：如果迁移中会调整栏目或改路径，提前做一张旧路径与新路径的对照表。这张表后面做跳转规则时直接要用。

适用前提：只要迁移后还要保持原有访问体验，这份清单就必须做。判断是否合格的标准是——拿这份清单给另一个人，他能独立说出原站有哪些页面、哪些要保留。

第二类记录：环境、账号与凭证

迁移失败最常见的原因不是技术难，而是缺账号、缺密码、缺参数。这类记录要在动手前整理完，不要边迁边找。

1. 域名相关：域名注册商、DNS 解析服务商、当前解析记录（A 记录、CNAME 记录等）。记录当前值，迁移后对比是否变化。
2. 服务器相关：原服务器的系统类型、Web 服务软件及版本、程序运行环境版本（如 PHP、数据库版本）。新服务器尽量对齐，避免因版本差异导致程序报错。
3. 账号凭证：服务器登录方式、数据库账号、网站后台管理员账号、FTP 或文件管理账号。凭证要放在安全的地方，不要写在公开文档里。
4. 第三方依赖：网站用到的短信、支付、统计、地图等外部服务的配置项和密钥，逐项列出，迁移后需要重新填写或确认。

检查项：迁移前用这些凭证实际登录一次，确认都能用。登录不上的，先解决登录问题，再开始迁移。

第三类记录：迁移过程与变更日志

迁移过程中做的每一步操作，都要留下时间、操作内容和结果。这份日志的作用是出问题时能定位，而不是靠回忆。

• 操作时间线：什么时候备份、什么时候上传、什么时候改解析、什么时候切换数据库。按时间顺序记。
• 备份记录：备份了哪些内容（文件、数据库、配置）、备份文件存在哪里、备份是否验证过可恢复。只备份不验证，等于没备份。
• 变更记录：改了哪些配置、换了哪些路径、调整了哪些跳转规则。每项写清楚改前和改后的值。
• 异常记录：迁移中出现的报错、页面异常、数据不一致，记下现象和处理方式。没解决的单独标出来。

假设一个例子：迁移后某个栏目页显示空白。如果有变更日志，可以查到该栏目对应的模板文件是否漏传、数据库里该栏目的记录是否完整；如果没有日志，只能从头排查，耗时成倍增加。

迁移后的验收信号

记录准备得对不对，最终要靠验收来验证。以下信号说明迁移基本到位：

• 用原站资产清单逐条访问，页面能正常打开，内容与迁移前一致。
• 数据库中的内容数量与迁移前记录的数量对得上，没有明显缺失。
• 旧路径访问时能正确到达新路径，不出现大量死链。
• 后台能正常登录，能发布或修改一条内容并生效。
• 域名解析已指向新服务器，且原服务器仍保留一段时间，便于回滚。

如果验收中发现对不上的项目，回到对应的记录里查：页面缺失查资产清单，数据缺失查数据库记录，路径错误查对照表，配置错误查变更日志。

下一步怎么做

现在就可以动手建三份文档：一份原站资产清单、一份账号与环境凭证表、一份迁移操作日志。先填资产清单和凭证表，填不出来的项目就是迁移前必须补齐的信息。填完之后，再安排备份和迁移时间，按日志逐项记录操作。这样即使第一次做迁移，也有可核对的依据，不至于中途失控。