订单恢复

本页面向负责支付流水、多服部署与异常订单的管理员。

订单状态

服务器在支付、发物品、增加货币或执行命令附近中断时，插件不会重做这些操作。不能确认结果的订单会进入 QUARANTINED，玩家界面显示“需要管理员核对”。

核对订单

/ss order inspect <订单 UUID>

建议按顺序检查：

1. 玩家、商品、数量和购买时间；
2. 扣款状态与支付方式的真实流水；
3. 玩家背包和物品；
4. 奖励货币的收支记录；
5. 命令目标插件的日志；
6. 当前商品奖励是否仍与原订单一致。

inspect 只读取订单，不会扣款、发奖或改变状态。

继续发放

/ss order retry <订单 UUID>

建议同时满足以下条件时才继续发放：

• 订单处于 QUARANTINED；
• 扣款已明确完成；
• 剩余奖励能够确认从未发放；
• 当前商品和原订单的奖励内容一致；
• 玩家在线，且背包能放下剩余物品。

该命令不会再次扣款，只从第一项尚未开始的奖励继续。支付结果不明、奖励可能已经执行、商品被删除或奖励配置已变化时，插件会拒绝重试。

人工确认完成

/ss order resolve <订单 UUID> complete

仅在已经从支付、背包、货币和命令记录确认所有内容都实际完成后使用。该命令只更新订单、优惠券和限购记录，不会再次发奖。

人工退款

/ss order resolve <订单 UUID> refund

玩家必须在线。插件会使用原支付方式退回实付金额，成功后释放限购，并归还尚未过期的优惠券。

如果支付服务抛出异常，退款结果无法确认，插件不会自动再次退款。管理员需要先检查支付流水，避免重复退款。

重启后的处理

服务端启动时会检查中断订单：

• 可以确认尚未开始扣款的订单会自动取消并释放优惠券与限购；
• 已开始扣款或发奖，但结果无法确定的订单会转为 QUARANTINED；
• 已完成、已取消和原本待核对的订单保持不变。

控制台会提示需要管理员核对的订单数量。

备份

SQLite

推荐先正常停止服务器，再同时备份：

• systemshop.db；
• config.yml、database.yml、redis.yml 与 language.yml；
• catalog/；
• 已修改的 ui/。

运行中直接复制单个 .db 文件可能遗漏尚未写回的内容。需要在线备份时，应使用 SQLite 的正式备份方式。

MySQL

• 使用支持事务一致性的 MySQL 备份；
• 同时备份所有子服使用的商品目录；
• 恢复时先恢复 MySQL 和相同的 YAML，再依次启动各子服；
• 每个子服继续使用原来的唯一 server-id。

多服发布商品目录

建议先在测试服完成无券、固定券、倍率券、限购和背包不足测试，然后：

1. 把相同的 catalog/ 同步到所有生产子服；
2. 逐台执行 /ss reload；
3. 确认每台都提示重载成功；
4. 重新打开客户端，测试浏览、报价和购买。

各子服商城配置不一致期间，SystemShop 会暂停报价和购买。Redis 只负责通知，不会自动分发 YAML。

数据保留

默认设置下：

• 已完成和已取消订单保留 180 天；
• 已使用、已过期和已撤销的优惠券保留 180 天；
• 旧日、周、月限购记录保留 120 天；
• 商品下架后的收藏与永久限购保留 365 天；
• 管理记录保留 180 天；
• 已停用子服状态保留 7 天。

处理中和需要核对的订单不会自动删除。商品仍在目录中时，其收藏和永久限购也不会按时间清理。修改这些周期见基础配置。

常见问题