wordpress换空间，需求清单应该写到什么程度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /45251b11ad16.html
📄
wordpress换空间，需求清单应该写到什么程度
需求清单写到“另一个人拿着它就能完成迁移并判断是否合格”的程度即可：每一条都对应一个可交付结果，写清源站与目标环境、要搬哪些内容、由谁操作、什么算完成、失败时怎么回退。低于这个程度，执行时必然反复确认；高于这个程度，会变成把操作步骤全部预写一遍，反而容易与实际环境脱节。
先定交付结果，再倒推清单条目
换空间的最终交付结果通常有三项：目标空间上站点能正常打开、后台能正常登录并发布内容、原空间在观察期内保持可回退。需求清单应围绕这三项写，而不是围绕“怎么点按钮”写。判断标准很简单：一条需求如果无法对应到某个可检查的结果，就属于过程描述，可以删掉或降为备注。
- 交付物：目标环境的站点文件、数据库、必要配置。
- 可用性：前台页面、后台登录、文章发布各验证一次。
- 可回退：原空间数据在确认前不被删除或覆盖。
必须写进清单的四类信息
第一类是环境信息：源空间与目标空间的 PHP 版本、数据库类型与版本、站点根目录、是否使用对象存储或 CDN。第二类是内容范围：数据库全量还是仅业务表、上传目录、主题与插件、伪静态规则、定时任务。第三类是责任划分：谁提供目标空间账号、谁执行打包与导入、谁做域名解析切换、谁负责验收。第四类是验收与回退：验收由谁在什么时间点做，观察多久，出问题回到哪个状态。这四类缺任何一类，清单都不算完整。
两种处理方案的适用条件
方案一：整站打包迁移。把文件和数据库一起搬到目标空间，改好配置后切换。适用条件是源站与目标站环境差异不大、插件依赖少、可以接受一段时间的停机或只读。它的清单要写到“数据库导出文件、文件压缩包、配置文件改动项、解析切换时点”这一层。
方案二：目标空间重建后导入内容。先在目标空间装好同一套程序，再导入数据库和上传目录，逐个确认主题与插件。适用条件是源空间环境老旧、版本差异大、或希望借迁移顺便清理无用插件。它的清单要额外写到“需要重新配置的项目”和“导入后需逐项验证的功能”，因为重建过程中最容易漏掉的是定时任务、邮件发送配置和支付类插件的密钥。
两种方案的选择依据不是哪个更快，而是环境差异和可接受的停机时间。差异小、停机窗口短，选整站迁移；差异大、希望顺带整理，选重建导入。清单的详细程度也应随之调整：重建方案的清单必须比整站迁移多出一份“重新配置项”列表。
验收清单要写成可执行的检查项
验收不要写“检查网站是否正常”这种无法判断的条目，要写成能直接操作的动作。例如：
- 打开首页、一篇旧文章、一个分类页，确认无报错。
- 用管理员账号登录后台，新建一篇草稿并删除。
- 上传一张图片，确认媒体库可写入且前台能显示。
- 提交一次表单或评论，确认写入数据库成功。
- 核对固定链接结构，确认内页地址与迁移前一致。
每项检查都要写明预期结果。比如第 5 项，预期是内页 URL 与原来相同；若不同，说明伪静态规则或站点地址配置未同步，需要回到清单里的对应条目处理。假设某个站点迁移后发现内页全部 404，按上述检查顺序就能定位到是重写规则问题，而不是数据库丢失——这只是假设示例，用于说明检查项要能区分不同原因。
写到什么程度算够，什么算过头
够用的清单满足三个条件：执行人不需要追问“搬哪些表”“谁来切解析”“出问题找谁”；验收人不需要追问“怎么算成功”；回退时不需要临时商量回到哪个状态。过头的清单则会把每一步点击都写进去，这类内容随程序版本和主机面板变化很快，写死在清单里反而会误导执行人。更稳妥的做法是：结果、责任、验收写细，操作步骤只写到关键节点，例如“导出数据库”“修改站点地址”“切换解析”，具体命令由执行人按当时环境决定。
下一步，把上面四类信息和验收项整理成一页表格，每行标注责任人和完成状态，迁移前后各核对一次，确认无空白项后再开始操作。
