VWCG-1078 PC 消费订单详情补打小票
核心结论：通过现有 Logic
orderPrint 的人工模式参数实现补打；不新增 ydy_meal_order_receipt_reprint，不需要 client_request_id，不生成 SQL。1. 为什么不能直接调用原接口
原打印逻辑只接受 print_status=PENDING，已打印订单会被跳过；原 Controller 还会把 Logic 的失败结果固定返回为“操作成功”。因此 PC 使用独立接口 /p/mealOrder/reprintReceipt，内部调用 orderPrint($orderId, 2, true)，并返回真实结果。
2. 业务资格
- 订单已支付、未取消、未全额退款；
- 订单按现有规则存在可打印小票内容；
- 用户拥有消费订单详情和对象数据权限。
print_status、补单标识和打印机当前状态不参与按钮显示。打印机、SN 和平台异常在点击后校验并提示。
3. 自动与人工模式
| 行为 | 自动模式 | 人工补打 |
|---|---|---|
| 入口状态 | PENDING | 不以 print_status 限制 |
| 提交前 | CAS 写 PRINTING | 锁内重读资格 |
| 受理 | 写 PRINTED 和 print_time | 订单状态不变 |
| 失败/未知 | 恢复 PENDING | 订单状态不变 |
4. 防重复与结果
人工与自动打印共享 Redis 订单锁，使用 SET NX EX 45 和 token 安全释放。人工受理或结果未知后设置 5 秒冷却；冷却写入失败时保留锁至 TTL。平台 code=0 且有非空任务标识才算 accepted；超时、连接异常或畸形成功响应为 unknown。
5. 接口
POST /p/mealOrder/reprintReceipt
{"order_id":12345}
accepted:
{"code":0,"message":"补打任务已提交","data":{"submit_status":"accepted"}}
unknown:
{"code":1,"message":"提交结果未知，请先检查打印机，避免重复补打","data":{"submit_status":"unknown"}}
6. 前端
按钮只在详情弹窗且资格可见时出现；确认框展示订单号；请求只传订单 ID；确认和网络阶段保持 loading；切换订单时清空旧详情并用请求序号隔离慢响应。accepted、failed、unknown 分别使用成功、错误、警告提示。
7. 数据、安全与导出
- 无新表、字段、索引或版本 SQL；不修改订单业务字段。
- 复用安全审计；审计失败不影响已经受理的打印结果。
- 日志不记录小票正文、完整 SN、姓名、手机号、密钥、签名或完整平台响应。
- 列表查询和字段未变，异步导出无需修改。
8. 验证
| 后端专项 | 40 tests / 184 assertions，通过 |
|---|---|
| 模板与设备配置回归 | 5 tests / 16 assertions，通过 |
| 前端 Jest | 6 tests，通过 |
| PC 构建 | 通过 |
后端专项现为 40 tests / 184 assertions，已验证所有打印状态均不影响人工入口，人工 accepted/failed/unknown 不改订单打印状态、立即重复只调用一次平台、冷却失败保留锁，以及自动打印原状态机。真实打印机未获授权，发布前需在隔离测试环境人工验收。
9. 发布与回滚
发布顺序为后端 Logic/Controller 与权限覆盖，再发布 PC 静态资源。无数据库步骤。回滚时同步回滚前后端代码即可。