南昌网站开发：网站迁移应准备哪些记录？先备好这份可核对清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1c3ed36bf2fb.html
📄
南昌网站开发：网站迁移应准备哪些记录？先备好这份可核对清单
网站迁移前最该准备的，不是一句“备份好了”，而是一套能还原现状、解释变化、定位故障的记录。对南昌网站开发项目来说，迁移可能只是换服务器、换域名、换程序版本，也可能是整体重做后上线。准备记录的目标很明确：迁移前知道有什么，迁移中知道改了什么，迁移后能判断哪里不对。最关键的一步是先建立一份“迁移前基线记录”，否则出问题只能靠猜。
准备阶段：先记录迁移前能正常工作的状态
基线记录要能在不打开网站后台的情况下，回答“迁移前是什么样”。建议至少保存以下内容：
- 域名与解析记录：当前A记录、CNAME记录、MX记录、TXT记录，截图或导出文本均可，注明记录时间。
- 服务器信息：操作系统版本、Web服务器类型与版本、数据库类型与版本、程序运行环境版本。不要只写“Linux+MySQL”，要写到具体版本号。
- 站点结构：主要栏目、页面URL样例、伪静态规则、重定向规则。用表格记录“原URL→预期新URL”的对应关系。
- 账号与权限：后台管理员、数据库账号、FTP或SSH账号的归属人，不记录明文密码，只记录由谁保管、在哪里取用。
- 备份记录：备份时间、备份方式、备份文件存放位置、是否做过恢复演练。只写“已备份”没有意义，要能指出用哪个文件恢复。
- 外部依赖：短信、支付、统计、地图、客服等第三方接口的调用地址和账号归属。迁移后这类接口常因IP白名单或域名授权失效。
如果迁移同时涉及南昌网站开发中的改版，还要额外记录旧页面的标题、描述和正文要点，作为迁移后内容比对的参照。没有这份参照，就无法判断流量变化是迁移造成还是改版造成。
实施阶段：记录每一次变更，而不是只记录结果
迁移实施时，最容易丢失的信息是“谁在什么时候改了什么”。建议用一张变更记录表，按时间顺序填写：
- 变更时间与操作人。
- 变更对象，例如DNS解析、数据库连接配置、伪静态文件。
- 变更前值与变更后值。
- 变更原因，例如切换服务器、修复路径错误。
- 变更后立即观察到的现象。
举例来说，假设某次迁移把数据库连接地址从旧服务器IP改为新服务器内网地址，记录里就应写明旧值、新值、修改的文件路径和修改时间。这样当页面报“数据库连接失败”时，可以先核对这项变更，而不是从头排查所有配置。这里要区分“可能原因”和“已经定位的原因”：连接失败可能是配置错误，也可能是数据库未启动或账号权限不足，只有逐项核对后才能下结论。
验证阶段：用检查项判断迁移是否真的完成
迁移完成后，不要只看首页能否打开。按下面几类检查，并记录每项的结果：
- 解析检查：用不同网络环境查询域名解析，确认返回的IP与预期一致。
- 页面检查：首页、栏目页、详情页各抽取若干条，确认状态码、页面内容和图片加载正常。
- 跳转检查：旧URL是否按记录中的规则跳转到新URL，是否存在跳转链条过长或跳回旧站的情况。
- 功能检查：表单提交、登录、搜索、支付回调等关键流程逐项走一遍。
- 收录相关检查：robots文件、站点地图、canonical标签是否指向正确地址。这里只做技术核对，不保证收录或排名结果。
验证结果要写成“检查项—预期—实际—结论”的形式。例如预期旧详情页返回301到新详情页，实际返回404，结论就是跳转规则未生效。这样的记录能直接交给开发人员处理，不需要再复述现象。
维护阶段：保留记录并设定复查节点
迁移结束不等于记录工作结束。至少保留迁移前的基线记录、实施变更记录和验证结果三份材料，并注明保存位置和保管人。迁移后的一段时间内，按固定节点复查服务器日志、错误日志和关键页面状态，把新发现的问题追加到同一份记录中，而不是另起一份。这样当问题反复出现时，能看出它是否与某次变更相关。
如果迁移后出现异常，下一步不是立刻回滚，而是先用基线记录和变更记录做一次对照：哪项配置与迁移前不同，哪项检查未通过。定位到具体差异后，再决定修复还是回滚。
