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

太原网站开发网站迁移应准备哪些记录：先整理一份可回滚的迁移台账

网站迁移前最该准备的，不是服务器账号，而是一份能让人独立完成回滚和验证的迁移记录。对太原网站开发项目来说，无论换主机、换域名、换程序还是改版，都应先把原站现状、迁移步骤、验证结果和回滚方式写成文档。最关键的一步是：在动手前完成原站完整备份，并记录备份存放位置、生成时间和校验方式，确保出问题时能恢复到迁移前状态。

准备阶段：记录原站现状与资源清单

迁移前要先把“现在有什么”记清楚，否则迁移后无法判断哪里丢了、哪里变了。建议建立一张清单，逐项登记：

• 域名与 DNS 记录：A 记录、CNAME、MX、TXT 等当前指向，记录修改前的值。
• 服务器信息：主机商、IP、操作系统、Web 服务软件及版本、数据库类型及版本。
• 程序与依赖：使用的 CMS 或框架版本、插件或扩展清单、PHP/Node/Python 等运行环境版本。
• 内容与数据：页面数量、栏目结构、图片和附件目录、数据库表清单及大致数据量。
• 账号权限：后台管理员、数据库用户、FTP/SFTP 或 SSH 账号，只记录角色和权限范围，密码放入密码管理工具，不写进普通文档。
• 备份记录：备份文件生成时间、存放路径、文件大小、校验值（如 MD5 或 SHA-256）。

这一步的适用条件是：只要迁移会改变域名解析、服务器环境或程序版本，就必须做。判断结果很简单——如果拿不出原站备份和资源清单，就不应开始迁移。

实施阶段：记录每一步操作与变更

迁移过程中最容易出问题的是“改了什么没人记得”。建议按时间顺序记录操作日志，至少包含：操作时间、操作人、操作内容、影响范围、是否已回滚。具体包括：

1. 备份操作：备份了哪些目录和数据库，使用的命令或工具，备份文件放在哪里。
2. 文件迁移：从哪台服务器传到哪台服务器，传输方式（如 rsync、SFTP），是否完整。
3. 数据库导入：导入的是哪个备份文件，导入后表数量和数据量是否与记录一致。
4. 配置修改：域名解析、Web 服务器配置、数据库连接、伪静态规则的改动前后值。
5. 程序调整：升级或替换了哪些组件，版本号变化，是否影响现有页面。

如果迁移涉及域名更换，还要单独记录旧域名到新域名的对应关系，以及需要保留的跳转规则。假设原站有 200 个页面，迁移后应能对照清单确认这 200 个页面是否都有对应地址，而不是只检查首页能否打开。

验证阶段：记录检查项与判断结果

迁移完成后，验证记录要能回答“哪些正常、哪些异常、异常如何处理”。建议按以下检查项逐条记录结果：

• 首页和主要栏目能否正常访问，状态码是否为 200。
• 页面样式、图片、脚本是否加载正常，有无 404 或 500 错误。
• 表单提交、搜索、登录等交互功能是否可用。
• 数据库读写是否正常，新发布内容能否保存和显示。
• 移动端访问是否正常，页面布局有无错位。
• 旧地址是否按预期跳转到新地址，跳转状态码是否正确。

验证时要把“可能原因”和“已经定位的原因”分开写。例如页面打不开，可能是 DNS 尚未生效，也可能是 Web 服务器配置错误，还可能是数据库连接失败；在未确认前不要只写一个原因。只有通过日志、解析结果或配置比对确认后，才记录为已定位原因。

维护阶段：记录回滚方案与后续观察

迁移记录的最后一部分是回滚方案。要写清楚：什么条件下触发回滚、回滚需要哪些文件和数据、回滚步骤由谁执行、预计多久完成。回滚方案必须和备份记录对应，不能只写“有备份”却不写备份在哪、怎么恢复。

迁移后一段时间内，还应记录每日或每次检查的结果，包括访问是否正常、错误日志有无新增异常、数据是否完整。如果发现异常，先对照迁移台账判断是解析、配置、程序还是数据问题，再决定修复还是回滚。

下一步建议：在正式迁移前，先用一份空白模板把上述准备、实施、验证、维护四类记录填一遍，确认每一项都有对应责任人和存放位置，再开始操作。