WPX Powerstore WooCommerce Staging：推送前先保护线上订单

购买前先核对Staging门槛

创建时线上数据库必须小于1GB、总文件小于5GB；只允许一个Staging；不支持Multisite；如果Staging数据库后来超过1GB，就无法Deploy。 磁盘还要同时容纳两个副本。

先测数据库和总文件，确认不是Multisite，并估算测试数据与日志是否会越过1GB。数据库已接近门槛时，不要假设一键Staging能解决上线；先向WPX取得当前书面方案，或使用只迁代码/选定数据的流程。

“替换线上”不等于“合并订单”

WPX说明Deploy会把Staging推到线上，并**替换当前线上版本**。 文档没有描述订单感知式合并。

假设周一复制Staging，周二线上新增37笔订单、3笔退款、2位客户并发生库存变化，周三把周一数据库推回线上。即使主题改动正确，完整替换仍可能把业务数据倒回周一。

InstaWP与WP STAGING的同意图资料也讨论了WooCommerce整库推送风险，以及选择性同步、排除数据表或订单导入导出。 这些不是WPX功能；它们只说明“Staging测试通过”不等于“线上推送安全”。

选择一种发布模型

低写入维护窗口

暂停结账与其他写入，立即备份，再Deploy、验证并恢复营业。暂停前记录最后订单号和支付结算，发布后逐项对比。

只迁代码或最小范围

订单不能暂停时，避免替换整个数据库，只迁必要主题、插件或配置。BlogVault的通用建议同样是先备份并推送最小范围。 具体可用方式必须先让WPX确认。

订单感知式协调

高交易量商店可能需要排除数据表、兼容HPOS或定制发布。 这是开发工作，不是主机勾选项。如果团队和WPX都说不清协调方法，就不要在订单持续产生时整库推送。

支付测试不能把副本当成第二个真实商店

用网关沙盒测试订单、库存、税费、配送、邮件、Webhook和计划任务；确认副本不能真实扣款；记录预期订单状态，发布后对照。

WooPayments文档说明克隆站与Safe Mode，提醒我们副本的支付身份不同于生产站。 不要为了让测试像线上而关闭保护。

WPX还说明Staging默认noindex，且XDN关闭。 这有助于避免收录，却也意味着Staging速度不能代表生产性能。

分清两种备份时钟

自动备份每日执行、存放在独立服务器并保留28天，但不能下载；Personal Backup可以下载，却只保留24小时。

切换前立即创建Personal Backup，在24小时内下载，独立保存数据库与关键上传文件，核对归档是否被跳过，并在事故前测试恢复。28天历史是恢复便利，不是唯一连续性计划。WPX条款仍把数据副本责任留给客户，也承认备份可能丢失或损坏。

订单安全上线清单

**创建前** - 记录数据库/文件大小和资格门槛； - 记录最后订单号、退款、库存与结算； - 移除真实密钥或启用测试模式。

**测试中** - 测试结账、回调、邮件、税费、配送、库存和计划任务； - 保持noindex并记住XDN关闭； - 阻止真实邮件与付款。

**Deploy前** - 明确暂停写入、只迁代码，还是协调数据； - 让WPX Support确认Deploy范围； - 创建并下载新Personal Backup，另存数据库； - 如暂停结账，提前公告维护窗口。

**Deploy后** - 对比订单号与支付状态； - 做一笔受控真实订单，检查库存、邮件与结算； - 检查日志、Webhook、计划任务、缓存排除与canonical； - 业务签字前保留回滚点。

谁适合买，谁不适合

如果是一家商店、看重明确WooCommerce资源，并能执行严格发布流程，Powerstore可能合适。 如果数据库已接近门槛、使用Multisite、无法暂停或协调订单，或团队误以为“托管”会自动合并线上数据，就不适合。

**结论：** 只有当团队能把Deploy当作受控数据操作时，Powerstore的Staging才有价值。先测门槛、再测支付、保护订单、下载新备份，并在发布后验证。最安全的默认认知是：**替换不是合并**。

WooCommerce的通用Staging指南与WP Desk都强调：商店副本用于受控测试，不能替代发布备份；Kinsta的托管主机文档也独立说明了整库覆盖这一类风险。