不能默认会合并。测试站推送可能覆盖选中的正式站文件和数据库表，测试期间正式站新增的数据可能因此被替换。应先确定需要发布的是代码、媒体还是具体数据，再核对当前WPvivid Staging Pro的选择范围与实际界面。
测试站是某个时间点副本
测试站创建后，正式站仍可能有新订单、会员、询盘和内容修改。两个环境会逐渐分叉，不能因页面外观相同就认为数据也一致。发布前记录测试站创建时间、正式站持续写入的数据类别和本次变更，避免把较旧数据库整体覆盖回去。
文件和数据库分别评估
主题或插件代码变更不一定需要整个数据库，页面布局和插件配置又可能确实存储在表内。先查变更的真实落点，不凭“只改了设计”就判断只复制文件即可。自定义内容选项能缩小范围，但正确选择依赖对具体插件存储结构的了解。
按表选择仍有关系约束
数据库表之间可能存在用户、订单和元数据关系，随意选一部分表也可能产生不一致。列出相关依赖，结合HPOS等实际存储方式评估，不照搬旧版posts订单假设。若无法安全确定覆盖范围，应改用更明确的发布方式，而非碰运气点全部推送。
推送前后各留业务证据
发布前保留正式站当前备份，并安排写入窗口或其他业务协调方案。发布后核对新近业务记录、媒体、布局和关键功能，不只看首页。所有演练使用隔离环境，不能通过真实下单或通知客户来测试推送，记录是否完成技术验证与业务确认。
关键区别
文件推送：更新程序和媒体；不代表同步设置。
数据库推送：可能覆盖业务表；不能默认合并。
自定义范围：减少覆盖对象；仍需查关联。
怎样确认处理到位
验证应能证明发布前最新业务记录仍在，所需布局与配置生效，未选范围没有被意外覆盖。没有完成数据核对时，不能只凭推送成功提示宣布发布验收。
容易误判的边界
不要把“暂存站推送”理解为自动解决数据冲突，也不要依靠临时全站停机掩盖不清楚的范围。工具功能和界面以当前版本与授权为准。
