ADR-001：订单明细与 custom_dish 上传分离
状态
已接受（2026-08-02）。
背景
熟食订单需要在本地保留多种商品的名称、单价、重量和金额，但现有订单的 categories 字段被离线补传逻辑直接解析为服务端 dishes 数组。熟食商品没有对应的服务端商品 UUID，现有服务端策略要求整单只上传一个 custom_dish。
如果将熟食明细直接写入 categories，离线补传会把多条本地明细当成多个服务端菜品，造成上传语义错误；如果只保存 custom_dish，又无法恢复本地熟食消费明细。
决策
订单同时保存两类数据：
categories：只保存一条与现有上传代码兼容的custom_dish摘要。cooked_food_details：在订单表中独立保存熟食明细和金额汇总，第一期采用版本化 JSON。
在线支付和离线补传均以 categories 作为服务端上传输入；本地订单详情、打印和查询以 cooked_food_details 作为熟食展示输入。
选项对比
| 方案 | 结论 | 原因 |
|---|---|---|
明细全部写入 categories | 否 | 离线补传会拆成多个服务端菜品 |
只保存一个 custom_dish | 否 | 本地丢失熟食明细，无法满足查询和审计 |
| 新增服务端熟食商品协议 | 本期不采用 | 超出本期范围，涉及后端商品模型和接口协同 |
独立保存本地明细并保留单 custom_dish | 采用 | 满足本地可追溯与现有上传兼容性 |
影响
正面影响
- 保持服务端接口和离线补传策略稳定。
- 本地可以完整恢复熟食消费过程和行项目。
- 未来可在不改上传协议的前提下增加打印、查询和统计能力。
代价
Order、OrderDao、订单数据库需要增加独立字段。- 订单创建、读取、详情展示和离线补传必须明确使用哪个字段。
- 需要增加 JSON 版本和解析失败降级处理。
验证要求
- 在线支付请求的
dishes数量始终为 1，且 UUID 为custom_dish。 - 离线订单的
categories只包含单条上传摘要。 - 离线补传后，本地
cooked_food_details仍可读取。 - 旧订单没有熟食字段时，沿用原有上传和展示逻辑。