领垫与设备执行流程

免费领取和在线购买的资格来源不同，但最终都需要驱动同一台实体设备。比较稳妥的设计是先生成业务订单，再由订单创建统一的设备任务，避免两条业务链路各自实现一套设备控制逻辑。

完整流程

sequenceDiagram
  participant U as 用户 H5
  participant A as 洁垫 API
  participant C as 微信 / 支付 / 任务渠道
  participant Q as 消息与设备服务
  participant D as 出垫设备

  U->>A: 扫码进入设备页面
  A-->>U: 返回设备状态和领取方式
  U->>A: 选择免费领取或购买
  A->>C: 校验活动资格或创建支付
  C-->>A: 返回有效结果
  A->>A: 创建订单与设备任务
  A->>Q: 下发出垫指令
  Q->>D: 投递设备命令
  D-->>Q: 回传执行结果
  Q->>A: 通知成功或失败
  A-->>U: 查询并展示最终状态

免费领取与购买

免费领取通常受每日次数、用户身份、设备位置和任务完成情况限制；在线购买则以支付回调为可信依据。两者都不能仅凭前端跳转或页面按钮状态发出设备命令。

可以用统一字段记录订单来源，例如 free、paid 或 campaign，但金额、领取数量和渠道流水仍需分别保存，便于退款、对账和运营分析。

结果状态

建议至少区分以下状态：

1. created：订单已创建，资格或支付待确认；
2. authorized：已获得本次出垫资格；
3. dispatched：设备命令已下发；
4. succeeded：设备确认出垫成功；
5. failed：设备明确执行失败；
6. unknown：请求超时，等待回执或人工处理。

“未知”不能直接当作失败重试，因为原设备可能已经完成动作。系统应先按任务编号查询或等待回执，再决定补发、退款或转人工。

异常处理

• 支付成功但设备失败：保留订单与失败原因，进入退款或补发流程；
• 设备离线：不要立即下发，提示用户更换设备或稍后处理；
• 缺垫：阻止创建新任务，并提醒运营人员补充耗材；
• 重复回调：按渠道流水和业务单号去重；
• 页面关闭：最终状态仍由服务端推进，用户可再次进入结果页查询。