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

什么是cms_网站迁移前要准备哪些记录：多人协作交付清单

网站迁移前应准备的记录，核心是让接手的人不靠口头询问也能独立完成迁移和复查。具体包括：原站内容与栏目清单、URL 对照表、账号与权限清单、环境与配置记录、变更与回滚记录。缺少任何一项，多人协作时就容易出现重复导入、链接失效、权限漏配和返工。下面按观察、判断、处理、复查的顺序说明。

先观察：迁移前要盘清哪些现状

迁移不是把文件复制过去就算完成。先建立现状记录，才能判断迁移后是否一致。建议至少记录以下内容：

• 栏目与页面清单：每个栏目路径、页面标题、所属模板、是否含表单或评论。
• 内容量统计：文章、产品、媒体文件的条数，按内容类型分别统计。
• URL 清单：原站可访问的地址，包括带参数或不带参数的版本，标注哪些是有效页面、哪些是重复或废弃页面。
• 账号与权限：管理员、编辑、投稿者等角色分别有哪些人，谁负责哪类内容。
• 环境信息：服务器类型、数据库版本、所用 CMS 及其版本、依赖的扩展或插件清单。

这些记录的作用是给迁移范围划边界。范围不清，多人协作时两个人可能同时改同一批页面，或者都以为对方会处理某个栏目。

再判断：哪些记录决定迁移能否顺利交接

记录不是越多越好，判断标准是“接手人能否据此复现结果”。可以按三个问题筛选：

1. 这条记录能否回答“这个页面原来在哪里、迁移后应该在哪里”？如果只能回答一半，就需要补上 URL 对照关系。
2. 这条记录能否回答“谁有权改、改完谁验收”？权限和责任人写不清，迁移后容易出现无人认领的空白栏目。
3. 这条记录能否回答“出问题怎么退回”？没有回滚记录，一次失败导入就可能覆盖原站数据。

举例说明：假设原站有一个产品列表页 /products/，迁移后计划改成 /shop/。只记录新地址不够，还要记录旧地址、对应关系、由谁负责设置跳转、复查时用什么方法确认跳转生效。这里提到的地址和路径只是假设示例，不是真实项目数据。

处理：把记录整理成可交付的清单

多人协作时，建议把记录集中到一份共享文档，并按角色拆分任务。可执行步骤如下：

1. 建立 URL 对照表，至少包含四列：原地址、新地址、处理方式（保留、跳转、删除）、负责人。
2. 导出内容清单，按内容类型分组，标注哪些需要重新上传媒体文件、哪些需要重建表单。
3. 整理账号与权限表，列出角色、人员、可操作范围，迁移后逐项核对。
4. 记录环境与配置，包括 CMS 版本、数据库连接方式、必要的扩展清单，避免新环境缺组件。
5. 写一份回滚说明：迁移前备份哪些数据、备份放在哪里、出现哪种现象时执行回滚。

需要区分“可能原因”和“已经定位的原因”。例如迁移后某页面打不开，可能是跳转未配置、也可能是新站没有对应内容、还可能是权限限制。在记录里应写成待检查项，而不是直接断言成某一个原因。

复查：迁移后按记录逐项验证

复查不是凭感觉浏览几个页面，而是拿迁移前的记录逐条对照。可用的检查项包括：

• 随机抽取原 URL，确认访问后到达预期的新地址，且不是错误页。
• 核对内容条数，与迁移前统计的数量一致，差异部分注明原因。
• 用不同角色账号登录，确认权限与迁移前记录一致。
• 检查表单、评论、搜索等交互功能是否仍可用。
• 确认备份文件存在且可读取，回滚步骤没有缺漏。

复查结果应回写到同一份记录中，标注通过、待修、已回滚。这样下一轮迁移或日常维护时，记录可以直接复用，不必重新盘查。

下一步：打开你当前的网站，先导出栏目与 URL 清单，再按上面的四列对照表补上负责人，把这份记录作为迁移交付的第一份文件。