2026-08-28 消费流水日志中文化与精简记录

变更原因

真机现场复核发现：一次“放盘后未查到订单”的简单流程会产生约10条业务流水，其中包含创建流水、重复餐盘、订单二次校验、终态和复位等可推导或高频正常事件；同时 事件 字段虽然 key 已中文化，但值仍为英文码，不利于直接阅读。用户确认事件值改为中文并采用精简策略；空行的最终确认口径是仅在一笔业务流程结束后增加，用于分隔不同业务，不是每个事件后都增加。

代码变更

• 新增统一的事件名称映射，所有新写入日志的 事件 值使用中文；未知事件保留原值，避免丢失后续扩展信息。
• 日志查看器把历史文件中的英文事件码实时显示为中文，不批量改写历史日志。
• 普通 JSON 事件只换行；仅 业务流程结束 事件写完后再增加一个空行，以分隔前后两笔业务。
• 接口 B 的“请求成功但无有效订单”合并为一次“订单查询完成”事件，直接携带失败原因。
• 移除创建流水、锁定期间重复餐盘、订单二次校验、终态、复位、阶段开始、成功武装、成功卡一致性检查和落库开始等可推导事件。
• 正常扫码器/读卡器状态不再写入消费业务流水；硬件失败仍记录。卡区未清空采用单次提示，状态恢复后才允许再次记录。
• 接口 C 首传和补传均按一次实际请求保留一个结果；空补传轮次不记录，有任务、失败或跳过时继续记录。
• 网络正常状态不记录，网络不可用继续记录，恢复联网仍会触发原有补传调度。

精简结果

“餐盘识别成功，但未查到待结算订单”的典型路径由约10条收敛为5条：

识别到餐盘 → 开始查询订单 → 订单查询完成（失败原因） → 餐盘已移走 → 业务流程结束

精简只压缩重复和正常状态日志。扣款前读卡、扣款、扣款后读卡、落库、接口 C、后台补传、网络异常、硬件异常和卡片中途移走等关键结果与失败证据继续保留。

格式示例

{"格式版本":2,"时间":"2026-08-28T11:15:01.001+08:00","事件":"识别到餐盘","业务流水号":"FLOW-1","餐盘号":"10001"}

{"格式版本":2,"时间":"2026-08-28T11:15:01.120+08:00","事件":"开始查询订单","业务流水号":"FLOW-1","餐盘号":"10001","接口":"接口B"}

{"格式版本":2,"时间":"2026-08-28T11:15:01.360+08:00","事件":"订单查询完成","业务流水号":"FLOW-1","结果":"失败","错误信息":"未查到待结算订单"}

业务边界

• 不修改订单判断、金额单位、读卡、扣款、接口 B/C、本地交易记录或3分钟补传规则。
• 结果、阶段及协议/服务端返回值本次不做无依据翻译；用户本次明确要求的是 事件 字段值中文化。
• ReaderLog 和 HTTP/协议日志继续承担底层硬件、APDU 和原始网络诊断，消费流水聚焦一笔业务的关键时间线。
• Token、完整卡号/UID、人员信息、余额快照、APDU 和完整接口报文继续禁止写入消费流水。

验证

• 针对性日志测试已通过，覆盖新日志中文事件值、历史英文事件码显示兼容、普通事件连续写入及仅业务结束后加空行。
• JDK 8 完整单测及 Debug APK 构建 BUILD SUCCESSFUL in 43s；95个测试、0 failure、0 error、0 skipped；git diff --check 通过；Debug APK 约61 MB。
• 真机需在安装新 APK 后复核典型无订单路径为5条，并继续覆盖正金额成功、卡片移走、接口 C 失败及补传场景。

Git 边界

本次仅编辑和验证，不执行暂存、提交、推送、分支切换、合并、清理或历史改写。