foodie-server/specs/006-orderstate/research.md

Research: 订单状态四字段分离

1. 现有状态字段分析

Decision: 保留旧 state 字段但重新编号，新增 delivery_status、pay_status、after_sale_status 三个字段。

Rationale: spec 明确要求参考美团做法。旧 state 将 0-13 的支付/订单/配送/退款状态混在一起，自取/堂食订单无法复用。拆分后每种关注点独立，各类型订单只使用相关字段。

Alternatives considered:

• 只加 type 判断不改字段：不同类型状态含义不同，查询和展示逻辑会变成大量 if-else，不可维护
• 保留旧 state 值不变：新值更简洁（0-4 vs 0-13），且旧系统未正式使用无需兼容

2. PosOrder 实体现有字段

Decision: 新增 deliveryStatus（Long）、payStatus（Long）、afterSaleStatus（Long）三个字段。废弃 diningStatus、isAccepted 等字段但保留不删。

Rationale:

• 实体已有 longitude/latitude，骑手距离排序可直接使用
• payType 字段已存在，可用于区分到付/在线支付
• qsId/qsImg 字段已存在，骑手端查询可直接用

3. MyBatis Mapper 改造策略

Decision: 在现有 resultMap 中新增三个字段映射，insert/update 语句同步添加。旧 SQL 查询方法保留不删。

Rationale:

• 旧方法（selectPosOrderList 等）使用旧 state 值，数据迁移后自然废弃
• 新列表接口使用 LambdaQueryWrapper，不走 XML 定义的条件查询
• insertPosOrder 和 updatePosOrder 是通用方法，必须包含新字段

4. 列表接口技术方案

Decision: 三个新列表接口统一使用 MyBatis-Plus LambdaQueryWrapper，前端传 tab 字符串参数，后端映射到四字段查询条件。

Rationale:

• 项目已集成 MyBatis-Plus（3.0.3 starter），LambdaQueryWrapper 可直接使用
• Tab 参数用字符串（pending/active/completed 等）语义清晰，与旧接口完全独立
• 状态展示文字由前端根据字段组合计算，后端只返回数据

Alternatives considered:

• 继续用 XML SQL：旧 SQL 条件用旧 state 值硬编码，改造工作量大且不直观
• 新建 DTO/VO：PosOrder 全字段序列化已够用，spec 要求前端切换成本低

5. 距离排序实现

Decision: 骑手端 newTask Tab 使用 LambdaQueryWrapper.last() 追加 MySQL ST_Distance_Sphere 函数排序。

Rationale: PosOrder 已有 longitude/latitude 字段，无需 JOIN PosStore。MySQL 5.7+ 支持 ST_Distance_Sphere。

6. 定时任务改造

Decision: 改造 TestTask.java 中的四个方法，使用新字段条件。

Rationale:

• testTiming()（未支付超时取消）：查 payStatus=0 AND state=0，设 state=4
• zidwancheng()（自动完成）：查 state=2 AND afterSaleStatus=0 且超时，设 state=3
• refundProcessing()：暂不改造（spec 明确本次不实现退款流程）
• checkAppointmentOrder()：条件可能涉及 state，需同步更新

7. 前端改造范围

Decision: 平台管理端（foodie-admin-vue）的订单列表页需改造筛选条件和状态展示。商家端（foodie-store）和用户端/骑手端为移动 App，不在本次范围内（spec 未提及）。

Rationale: spec 第 16 节明确描述了平台管理端的改造细节，是本次需求的明确范围。

8. 数据迁移策略

Decision: 不需要数据迁移。历史订单数据由开发者手动清空。

Rationale: spec 明确"系统未正式使用"，新字段通过 ALTER TABLE 添加后所有新订单直接使用新值。旧数据手动清空即可。