# 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 添加后所有新订单直接使用新值。旧数据手动清空即可。