明确两套环境的用途
测试环境用于验证配置、数据导入、接口和功能调整；正式环境承担真实客户订单与往来。环境名称、访问地址与账号应能明显区分，让业务人员知道操作会产生什么影响。
例如财务在测试环境演练退款，应使用测试资料和对应测试通道。复制生产订单进行验证前，要考虑客户资料和资金接口的影响，避免测试操作触发真实通知或资金执行。
数据库与文件应有清晰边界
分别记录数据库名称、连接配置、图片及附件位置。测试环境不能因复制配置而误连正式数据库；测试文件也不能覆盖正式商城图片。检查时从应用实际读取的配置入手，而不是只看服务器上的文件夹名称。
需要使用业务样本时，应按权限准备必要数据并处理敏感信息。迁入测试环境的数据范围、日期和处理方法需要登记，便于解释验证结果与正式数据之间的差异。
外部接口按环境核对
支付、短信、消息推送和ERP回写要分别确认账户、回调与开关。无法提供独立测试服务的接口，可按双方约定使用受控验证方式，并明确哪些动作会影响外部正式系统。
接口联调记录不仅包括请求成功，也包括失败、重复通知、超时和对账。测试完成后更换正式配置时，重新核对服务主体和地址，不能只替换一个密钥便假定全部配置正确。
发布包与配置分别管理
登记源码版本、构建环境、应用包、数据库变更和配置差异。发布人员应知道本次修改涉及哪些终端与业务规则，避免只更新一个入口而让其他终端继续使用不匹配的处理方式。
敏感配置不写入公开源码或普通日志。配置模板可以描述字段用途，真实密钥由企业授权人员在对应环境设置，并控制访问权限。
切换时关注仍在处理的订单
发布前盘点待审核、待出库、在途、退款中和待结算业务。若变更影响状态或字段，需要说明旧单如何继续处理、新单从何时应用新规则。
确定暂停操作的窗口、通知人员和恢复条件。上线后按同一组场景检查登录、查价、下单和后续处理；发现异常时先保留证据并限制影响范围。
回退必须考虑上线后新数据
回退应用与恢复数据库不是同一个动作。系统启用后已经产生的新订单、付款与出库，不能因回退代码而被直接丢弃。回退方案需要说明变更是否兼容、哪些数据必须保留、谁批准执行。
演练时记录操作步骤和验证结果。只保存旧安装包而没有数据库、文件和外部状态的处理安排，尚不足以应对正式切换故障。