主因是后端业务归属 Bug，配置漂移是触发条件。
系统取到了设备，却把接口认证档口写进订单。设备管理改对了，不代表订单会跟着改对。
源码置信度：高Root Cause & Remediation Review · 2026-08-10
档口错归不是前端显示问题，留样柜也不只是设备问题。
这是开发前审核稿：把根因、证据、改进项、历史数据边界、测试验收和回滚方案一次讲清。当前未修改业务代码、生产配置或数据库。
01 · EXECUTIVE VERDICT
先判断：Bug 还是设置问题？
若确属江西 206，直接原因是配置未启用；静默成功则是代码缺陷。
目标配置有 WebSocket 地址，但没有显式打开同步开关；发送失败后又缺少真实失败回传。
源码置信度：中高，错误码待补证统一判断：两项都不是订单页面前端渲染导致。售卖柜错误已经落进订单归属；留样柜问题发生在服务端配置与 WebSocket 推送链。
02 · EVIDENCE BOUNDARY
哪些已证实，哪些还不能写死
已证实
- 设备档口和接口认证档口是两份独立数据。
- 售卖柜下单仍使用认证档口。
- 订单页按订单落库档口展示。
- 留样柜全局开关默认关闭。
- 江西 206 配置未显式开启该开关。
- 推送失败后上层仍可能得到成功。
发布前必须补证
- 群聊项目是否确实为江西 206。
- 生产认证档口是否就是“二楼自助档口”。
- 部署实际加载的环境和业务配置。
- 留样柜具体错误码、设备状态与服务端日志。
- 历史错归订单的时间范围、笔数和金额。
边界：“江西 206”来自售卖柜历史提交说明，不是群聊文字本身。若现场属于其他项目，必须按真实商户配置重新核验。
03 · VENDING CABINET
售卖柜为什么会归到错误档口
设备管理
→
只更新
equipment.restaurant_id售卖柜下单
→
解析到
equipment_code，但档口仍取 api_auth.restaurant_id消费服务
→
优先信任传入档口，不再根据设备回查
订单与报表
→
订单档口落错，展示与按档口收入统计一起错归
双真源漂移
设备档口与认证档口都能代表订单归属，却没有同步和冲突规则。
入口主动覆盖
即使设备档口正确，入口仍把旧认证档口作为有效值传下去。
不止列表名称
订单、档口收入、餐段及依赖档口的规则都有潜在影响。
04 · VENDING REMEDIATION
售卖柜优化明细
P0
订单真源精准修复
- 在售卖柜入口一次解析完整设备上下文：设备 ID、编号、SN、档口和解析来源。
- 认证绑定设备与请求
jqbh同时存在时必须是同一设备；冲突则拒绝下单并告警。 - 已解析到设备时，订单档口固定取设备档口。
- 无设备时只保留受控兼容回退，并记录告警；设备无有效档口时不得默认写档口 1。
- 只改售卖柜入口，不顺带改变普通消费机、H5、订餐等通用消费渠道。
P1
配置一致性治理
接口认证页面展示绑定设备、设备档口与认证档口的一致性；增加只读巡检，逐步取消双真源。
P2
历史订单治理
先只读导出候选订单并按设备变更时间勾稽，再单独授权写修复。严禁无时间边界批量 UPDATE。
| 关键测试 | 通过标准 |
|---|---|
| 认证档口旧、设备档口新 | 订单使用设备档口，并生成漂移告警。 |
| 认证设备与 jqbh 不同 | 拒绝下单，不产生订单。 |
| 认证未绑设备、jqbh 唯一有效 | 按兼容规则使用该设备及其档口。 |
| 设备已删除或无档口 | 明确失败，不冒用其他设备、不默认落档口 1。 |
| 普通外部订单、退款、出货上报 | 行为与修复前一致。 |
05 · SAMPLE CABINET
留样柜为什么“读不到菜单”
菜品 / 菜谱变化
→
进入
LockLygPush配置开关
→
江西 206 未覆盖全局
false，入口直接不发送即使开启
→
只选有效、已配对留样柜；写帧后不读设备业务 ACK
发送异常
→
只写日志，外层仍可能显示“已发起/完成”
不能越界：群聊没有具体错误码。开关遗漏足以解释“完全收不到菜单”，但不能据此断言设备弹窗的唯一根因。
06 · SAMPLE REMEDIATION
留样柜优化明细
启用前预检
- 确认项目、实际环境配置和开关状态。
- 核对设备类型、配对状态、编号、SN 和版本。
- 从应用服务器测试 WebSocket 端口与握手。
- 初始化命令先
--dry-run，核对范围和数量。
真实失败回传
- 区分未启用、无目标设备、部分失败、全部发送。
- 命令真实失败时退出非 0。
- 失败批次不能继续打印普通成功结论。
- 仅写帧成功只能称“服务端已发起”。
有限重试与追踪
- 只对瞬时网络错误做有限重试和总时限。
- 参数错误、设备无效、协议拒绝不重试。
- 增加消息 ID，支持批次与设备定位。
ACK、指标与告警
- 取得厂商协议后读取设备 ACK。
- 统计目标、发起、连接成功、确认和失败数。
- 连续失败、无目标设备和长期无确认触发告警。
| 状态 | 对外口径 | 系统行为 |
|---|---|---|
| 功能关闭 | 未启用 / 已跳过 | 不连接；初始化命令退出非 0。 |
| 无目标设备 | 无符合条件设备 | 不再标记成功。 |
| 部分设备失败 | 部分失败 | 返回数量与失败设备定位，命令退出非 0。 |
| 写帧成功 | 服务端已发起 | 等待 ACK 或现场回读。 |
| 设备业务 ACK | 设备已接收 / 已处理 | 完成消息级对账。 |
07 · DELIVERY PLAN
审核通过后，我会按这个顺序开发
A
证据冻结
确认项目、配置与设备；生产只读查询候选订单；补错误码截图与日志。无生产写操作。
B
最小代码修复
先补失败测试，再修改售卖柜入口、留样柜推送结果与命令退出语义；不顺手重构其他渠道。
C
本地与灰度验收
构造档口漂移用例；单台售卖柜小额测试；留样柜先 dry-run，再限定范围小批量发送。
D
历史数据另行审批
候选清单、金额、备份和回滚方案全部审完后，才允许事务化小批量修复。
第一批包含
售卖柜设备真源、冲突校验与测试；留样柜真实结果、命令退出与测试；脱敏结构化日志。
第一批不包含
直接改生产配置、直接改历史订单、擅改厂商协议、通用消费链重构、前端视觉改版。
08 · ACCEPTANCE
最终必须看见的结果
售卖柜验收
- 测试订单设备与目标售卖柜一致。
- 订单档口等于设备档口，列表显示超市档口。
- 配置漂移有告警，设备冲突不产生订单。
- 明细金额与按档口汇总可对账。
- 普通外部订单、退款和出货上报回归通过。
留样柜验收
- 明确看到实际加载配置和开关状态。
- dry-run 的菜品、菜谱、日期与档口范围正确。
- 每台设备有已发起或失败结果，失败退出非 0。
- 设备读到
foodInfo与preFoodInfo。 - 错误代码消失，或已按厂商码表形成独立结论。
09 · REVIEW DECISIONS
请审核这 8 个决策点
确认群聊对应江西 206；若不是，提供项目或域名重新核验。
同意售卖柜订单以已认证 / 已解析设备档口为真源。
同意认证设备与
jqbh 冲突时拒绝下单。选择无设备时“短期告警回退”或“直接强制失败”。
同意修复留样柜静默成功，真实失败时命令退出非 0。
同意取得厂商 ACK 前，成功口径只写“服务端已发起”。
授权生产脱敏配置、设备、订单和日志的只读核验。
历史订单写修复暂不授权，待候选清单和金额另审。
推荐审核口令
审核通过，先按 P0 开发；允许生产只读核验，不允许直接改历史订单。审核结论
通过 / 需修改 / 驳回 / 阻塞
通过 / 需修改 / 驳回 / 阻塞
开发授权边界
待审核人填写
待审核人填写
认可做法
待审核人填写
待审核人填写
否定做法
待审核人填写
待审核人填写
10 · SOURCE INDEX
源码证据索引
| 证据 | 位置（基线 10475011e） |
|---|---|
| 设备档口保存 | deviceManagement.vue:562-585；Equipment.php:255-275 |
| 售卖柜设备与档口参数 | Shop.php:35-112 |
| 订单档口优先级 | Consume.php:2128-2141 |
| 订单列表档口展示 | MealOrder.php:806-875；consume/index.vue:211-220 |
| 留样柜全局与江西 206 配置 | application/config.php:611-616；zhct_jx206/config.php:51-58 |
| 推送与设备筛选 | LockLygPush.php:21-235 |
| WebSocket 边界 | WebSocketClient.php:16-83 |
| 初始化命令 | LockLygInitPush.php:61-90 |
| 项目归属线索 | 历史提交 1617ddb36：江西206售卖柜接口与PC订单设备支持 |
Markdown 真源：原因分析及改进优化审核稿。页面未包含认证凭据、支付信息或生产敏感数据。