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

快速网站建设-网站迁移应准备哪些记录：一份可核对的清单

网站迁移前最该准备的记录，是能完整还原“旧站有什么、放在哪、怎么运行”的一套档案。缺少这套档案，迁移后容易出现页面丢失、链接失效、样式错乱，甚至无法回滚。下面从一个假设例子展开，说明该记录什么、怎么检查、常见错误在哪。

假设案例：一个小型企业站要从旧主机搬到新主机

假设你有一个约 50 个页面的企业展示站，原来放在共享主机上，现在要换到另一台服务器。迁移前，你至少应整理出以下记录，而不是直接打包上传：

• 文件清单：网站根目录、主题目录、上传目录、配置文件分别在哪里，总大小多少。
• 数据库记录：数据库名、用户名、主机地址、字符集、表前缀，以及导出的 SQL 文件存放位置。
• 域名与解析记录：当前 A 记录、CNAME 记录、MX 记录、TTL 值，以及 DNS 服务商是谁。
• 运行环境记录：服务器操作系统、Web 服务器类型、PHP 或运行时版本、必要的扩展模块。
• 页面与链接记录：主要栏目 URL、重要内页 URL、是否有伪静态规则、是否有重定向配置。
• 账号与权限记录：后台管理员、数据库账号、FTP 或 SSH 账号，以及各自权限范围。

这些记录的作用是：迁移时逐项核对，迁移后逐项验证。缺少任何一项，都可能让排查变成猜谜。

迁移前必须落盘的记录项与检查方法

记录不是抄一遍界面文字，而是留下可验证的证据。可以按下面顺序执行：

1. 导出前先记录体积与数量。统计文件总大小、文件总数、数据库表数量。迁移后对比这些数字，能快速判断是否漏传。
2. 保存一份原始配置文件。把旧站的配置内容复制到本地文本文件，注意隐藏数据库密码等敏感信息，不要直接公开。
3. 记录 URL 规则。如果旧站使用伪静态，记录规则原文；如果没有，明确写“无伪静态”。迁移后若新环境不支持同类规则，需要提前准备替代方案。
4. 记录 DNS 的 TTL。TTL 决定解析变更后多久生效。迁移前可适当调低 TTL，但这一步需要根据 DNS 服务商的实际能力判断，不是所有服务商都允许任意调整。
5. 记录回滚方式。旧站文件与数据库在迁移完成并验证前不要删除，保留原主机可访问状态，作为回退路径。

判断结果的标准很简单：拿着这份记录，另一个人能否在不问你任何问题的情况下，把旧站还原出来。如果能，记录就算合格。

常见错误：记录成了“大概记得”

迁移中最常见的错误不是技术难，而是记录模糊。例如：

• 只记了“数据库在服务器上”，没记数据库名和表前缀，导入后页面空白。
• 只记了“域名解析改一下”，没记 MX 记录，迁移后企业邮箱收不到信。
• 只备份了网站目录，没备份上传目录，迁移后图片全部裂开。
• 只记录了首页地址，没记录栏目页地址，迁移后内页 404。

这些错误的共同点是：记录时觉得“这个肯定记得”，迁移时才发现记不住。解决办法是把记录写成外部文档，而不是留在脑子里。

迁移后按记录逐项验证

迁移完成不等于结束。应按迁移前的记录逐项核对：

• 文件总数与总大小是否一致，不一致时先查上传目录和缓存目录。
• 数据库表数量是否一致，页面内容是否完整显示。
• 首页、栏目页、内页各抽查若干，确认没有 404 或样式丢失。
• 表单提交、搜索、登录等交互功能是否正常。
• DNS 解析是否已指向新主机，邮箱记录是否仍然有效。

如果某项对不上，先回看记录，判断是记录本身有误，还是迁移操作漏了步骤。不要在没有记录的情况下直接改配置，否则容易把可回滚的状态改乱。

下一步：把记录变成一份迁移检查表

现在就可以新建一个文本文件，按“文件、数据库、域名、环境、链接、账号、回滚”七项各写一行，填入你当前站点的实际信息。填不出来的项目，就是迁移前需要先查清的项目。这份表完成后，再开始打包和上传，迁移过程会清楚得多。