WordPress 测试站验收通过后，哪些设置不能直接覆盖正式站？

测试站的主题修改已经验收，正式站这几天却还在接收询盘、更新文章，甚至产生订单。此时把测试数据库整份推回正式站，会把“发布代码”变成“用旧业务数据覆盖新业务数据”。

交付前应先列清本次要带过去的变化：代码更新、特定设置和必要内容分别处理。运行中的正式数据与环境专属配置，不能因为测试通过就被默认纳入同步。

验收通过的，到底是什么？

“测试站正常”只是一个观察结果，还不足以定义发布范围。主题样式改动、插件升级与后台配置变化，可能涉及完全不同的存储位置。请开发人员明确每项变化来自文件、数据库设置，还是两者共同作用。

例如只改了产品页布局，就应先确认布局是否保存在主题代码、页面构建器数据或模板设置中。不能看到它出现在测试站，就推断复制某个目录一定足够；也不能为了省事连用户与订单一起搬。

这些差异需要保留或单独转换

• 正式业务数据：测试副本建立之后新增的文章、询盘、用户与订单。它们不是测试结果的一部分。
• 站点地址与资源地址：测试域名不能出现在正式页面链接、图片路径或对外标记中；具体存放位置要按实现查。
• 邮件与外部服务配置：测试收件人、测试账号、回调地址与正式环境各有用途，不应混用。
• 访问和索引设置：测试环境的访问限制与正式站的公开状态不同，发布后要检查实际响应，而不只看后台开关。

光算的WordPress 多环境同步与配置区分说明按代码、配置、内容和回滚整理了这些边界，适合用来准备交接范围表。表中应写“哪些项目允许改变”，而不是笼统写“测试与正式保持一致”。

地址替换工具不能替你决定同步范围

需要迁移地址时，先确认目标环境和待处理数据。WP-CLI 的 search-replace 官方说明指出，它可以处理PHP序列化数据；使用 --dry-run 会生成报告而不保存替换。它也允许限定表或列。

这些能力有助于核对替换范围，但不会判断哪笔订单更新、哪个设置应以正式站为准。预演输出也不等于业务验收。不要把任意网上命令直接用于生产，更不能把一个替换命令当成“安全合并两套数据库”的工具。

计划里写清工具执行者、实际范围、备份位置和检查方法。涉及敏感配置时，记录配置项名称与管理位置即可，不把密钥复制到普通交接文档。

上线前后各留下什么记录

发布前记录代码版本、被批准改变的设置、需要保留的业务数据范围，以及当次一致性备份的时间。对仍在写入的业务，应安排合适的迁移窗口与一致性方案；是否暂停某项写入要按业务决定，不能用一句“已备份”代替设计。

发布后至少走通一条真实页面路径：打开首页、进入列表、再进入详情；核对最终地址、可见内容和必要的联系入口。涉及邮件或结账的变更，要另用约定的测试方式确认对应链路，而不是把页面200当作整站功能正常。

回滚也要区分层次。换回旧代码与恢复旧数据库不是同一件事：后一种可能丢掉上线之后的新业务数据。事先写明回退对象、触发条件和数据处理方式，接手团队才不会在故障时凭感觉恢复整个站。