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

龙岩做网站网站迁移应准备哪些记录：先整理清单还是先停机，怎么选

网站迁移前应先准备一份可核对的记录清单，再决定停机窗口。对“龙岩做网站”这类本地建站项目来说，迁移记录的核心不是服务器参数越多越好，而是能回答三个问题：原站有什么、新站要接什么、出问题后凭什么回退。若记录不全就停机，代价是排查时间成倍增加；若记录过细但没人核对，代价是迁移当天仍会漏项。比较两种处理方案时，建议把“先整理清单再停机”作为默认选择，只有在同机房、同服务商、同数据库版本且可快速回滚的小型静态站迁移中，才考虑边迁移边补记录。

迁移前必须落盘的记录类别

记录要按“能恢复、能验证、能交接”来分组，而不是按个人习惯堆在一起。至少包括以下内容：

• 域名与解析记录：域名注册商、DNS 服务商、当前 A 记录、CNAME 记录、MX 记录、TXT 记录、TTL 值。TTL 越小，切换生效越快，但解析压力略增。
• 服务器与运行环境：操作系统版本、Web 服务器类型与版本、PHP 或 Node 等运行环境版本、数据库类型与版本、端口开放情况。
• 网站程序与数据：CMS 名称与版本、主题或模板名称、插件清单及版本、数据库表前缀、上传目录路径、伪静态规则。
• 账号与权限：后台管理员账号、数据库账号、FTP 或 SFTP 账号、对象存储密钥。密码不要写在公开文档里，应使用密码管理工具另存。
• 备份与回退点：迁移前完整备份的文件包、数据库导出文件、备份时间、校验值、存放位置。
• 外部依赖：短信接口、支付接口、统计代码、CDN、SSL 证书签发方式与到期时间。

这些记录的作用是：迁移后逐项比对，而不是凭记忆判断“应该没问题”。

两种处理方案的适用条件与代价

方案一：先整理完整记录，再安排停机迁移。适用条件是站点有数据库、有用户提交数据、有支付或会员功能，或者不能接受长时间无法访问。代价是准备阶段多花时间，通常需要提前几天逐项核对。好处是迁移当天按清单执行，出现 404、数据库连接失败、样式丢失时能快速定位是解析、环境还是数据问题。

方案二：先迁移，遇到问题再补记录。适用条件是纯静态页面、无数据库、无表单，且新旧环境由同一服务商提供，可随时回滚。代价是迁移过程中一旦出现解析冲突或文件覆盖，排查依据不足，容易把原站也改坏。它节省的是准备时间，增加的是故障恢复时间。

判断选哪种，可以看三个检查项：站点是否依赖数据库；是否已有可用的完整备份；停机一小时是否会影响咨询或订单。三项中有一项为“是”，就应选方案一。

可执行的迁移记录核对步骤

按下面顺序执行，每一步都留下可检查的结果：

1. 导出原站数据库，记录导出时间、文件大小和存放路径。恢复时用同一版本数据库导入，避免字符集不一致导致乱码。
2. 打包原站文件，排除缓存目录和临时文件。记录压缩包校验值，例如用 sha256sum 生成一串字符，迁移后比对是否一致。
3. 在新环境部署后，先不改 DNS，用本地 hosts 或临时域名访问，检查首页、栏目页、详情页、搜索页和后台登录页。
4. 核对伪静态规则。若原站使用 <h2> 这类内容标签不影响迁移，但 URL 重写规则必须一致，否则会出现大量 404。
5. 确认 SSL 证书已在新环境生效，再切换 DNS。切换后观察解析是否生效，可用不同网络环境访问验证。
6. 保留旧环境至少一个完整访问周期，确认新站稳定后再下线。回退时把 DNS 指回旧 IP，并恢复旧数据库。

假设一个龙岩本地企业站，原站使用某 CMS，有产品展示和留言功能。迁移前记录了数据库版本、插件清单和留言表前缀；迁移后发现留言页空白，核对记录发现新环境缺少对应插件，补装后恢复。这个例子的价值在于：记录让问题范围从“整站坏了”缩小到“某个插件缺失”。

迁移后需要留意的判断结果

迁移完成不等于记录工作结束。应检查：页面返回状态码是否正常；后台能否发布内容；表单能否提交并写入数据库；图片和附件路径是否正确；统计代码是否重复或缺失。若出现收录波动，不要立刻断定是迁移导致，应先确认 robots 文件、死链和重定向规则是否按记录执行。只有记录与现场一致，才能把“可能原因”和“已经定位的原因”分开。

下一步建议：把上述清单整理成一页核对表，按“迁移前、迁移中、迁移后”三栏标注负责人和完成时间。迁移当天只做核对和勾选，不再临时决定改配置。