# 订单状态筛选统一方案

## 问题描述

原先前端移动端和后台管理系统的订单状态筛选逻辑不一致：

### 移动端原有问题：
1. 使用多个字段组合进行筛选（payStatus, orderStatus, deliveryStatus）
2. 在前端进行二次过滤，效率低下
3. 筛选逻辑复杂，容易出错
4. 与后端设计的 statusFilter 字段不一致

### 后台管理系统：
1. 已经使用 statusFilter 字段
2. 但注释和实现有些不一致的地方

## 解决方案

统一使用后端的 `statusFilter` 字段进行订单状态筛选，所有前端页面都采用相同的筛选逻辑。

## 后端 statusFilter 字段定义

根据后端 `ShopOrderParam.java` 和 `ShopOrderMapper.xml` 的定义：

```java
@Schema(description = "订单状态筛选：-1全部，0待支付，1待发货，2待核销，3待收货，4待评价，5已完成，6已退款，7已删除")
private Integer statusFilter;
```

## 统一的状态筛选映射表

| statusFilter | 标签名称 | 后端筛选条件 | 说明 |
|-------------|---------|-------------|------|
| undefined   | 全部    | 无筛选条件   | 显示所有订单（包括已删除的） |
| 0          | 待付款   | pay_status = false | 未付款的订单 |
| 1          | 待发货   | pay_status = true AND delivery_status = 10 | 已付款但未发货 |
| 2          | 待核销   | pay_status = true AND delivery_status = 10 | 与待发货相同（特定业务场景） |
| 3          | 待收货   | pay_status = true AND delivery_status = 20 | 已发货待收货 |
| 4          | 待评价   | order_status = 1 | 与已完成相同（特定业务场景） |
| 5          | 已完成   | order_status = 1 | 订单已完成 |
| 6          | 已退款   | order_status = 6 | 退款成功的订单 |
| 7          | 已删除   | deleted = 1 | 已删除的订单 |

## 前端实现

### 移动端（React/Taro）

```typescript
// 统一的订单状态标签配置
const tabs = [
  {
    index: 0,
    key: '全部',
    title: '全部',
    description: '所有订单',
    statusFilter: undefined // 不传statusFilter，显示所有订单
  },
  {
    index: 1,
    key: '待付款',
    title: '待付款',
    description: '等待付款的订单',
    statusFilter: 0 // 对应后端：pay_status = false
  },
  {
    index: 2,
    key: '待发货',
    title: '待发货',
    description: '已付款待发货的订单',
    statusFilter: 1 // 对应后端：pay_status = true AND delivery_status = 10
  },
  {
    index: 3,
    key: '待收货',
    title: '待收货',
    description: '已发货待收货的订单',
    statusFilter: 3 // 对应后端：pay_status = true AND delivery_status = 20
  },
  {
    index: 4,
    key: '已完成',
    title: '已完成',
    description: '已完成的订单',
    statusFilter: 5 // 对应后端：order_status = 1
  },
  {
    index: 5,
    key: '已取消',
    title: '已取消',
    description: '已取消/退款的订单',
    statusFilter: 6 // 对应后端：order_status = 6 (已退款)
  }
]

// 筛选参数生成
const getOrderStatusParams = (index: string | number) => {
  let params: ShopOrderParam = {};
  params.userId = Taro.getStorageSync('UserId');

  const currentTab = tabs.find(tab => tab.index === Number(index));
  if (currentTab && currentTab.statusFilter !== undefined) {
    params.statusFilter = currentTab.statusFilter;
  }

  return params;
};
```

### 后台管理系统（Vue）

```typescript
const onTabs = () => {
  const filterParams: Record<string, any> = {};

  switch (activeKey.value) {
    case 'all':
      // 全部订单：不传statusFilter参数
      break;
    case 'unpaid':
      filterParams.statusFilter = 0;
      break;
    case 'undelivered':
      filterParams.statusFilter = 1;
      break;
    case 'unreceived':
      filterParams.statusFilter = 3;
      break;
    case 'completed':
      filterParams.statusFilter = 5;
      break;
    case 'refunded':
      filterParams.statusFilter = 6;
      break;
    case 'deleted':
      filterParams.statusFilter = 7;
      break;
  }

  reload(filterParams);
}
```

## 优化效果

### 1. 性能提升
- 筛选逻辑在后端执行，减少前端数据处理
- 减少网络传输的数据量
- 提高查询效率

### 2. 代码简化
- 移除前端复杂的筛选逻辑
- 统一前后端筛选标准
- 减少维护成本

### 3. 一致性保证
- 前端移动端和后台管理系统使用相同的筛选逻辑
- 与后端设计保持一致
- 避免数据不一致的问题

## 注意事项

### 1. 移动端特殊处理
移动端可能需要将某些后端状态合并显示：
- "已取消" 标签可以包含多种取消状态（orderStatus: 2,3,4,6,7）
- 可以在前端显示时进行状态文本的转换，但筛选仍使用 statusFilter

### 2. 向后兼容
- 保持现有API接口不变
- 逐步迁移现有代码
- 确保不影响现有功能

### 3. 测试验证
- 验证各个状态筛选的正确性
- 确认前后端数据一致性
- 测试边界情况和异常处理

## 迁移步骤

1. **创建新的移动端组件**：使用统一的 statusFilter 逻辑
2. **更新后台管理系统**：完善注释和实现细节
3. **测试验证**：确保所有筛选功能正常工作
4. **逐步替换**：将旧的移动端组件替换为新组件
5. **清理代码**：移除不再使用的筛选逻辑

## 相关文件

- 移动端新组件：`src/views/shop/shopOrder/mobile/index.tsx`
- 后台管理系统：`src/views/shop/shopOrder/index.vue`
- API接口：`src/api/shop/shopOrder/index.ts`
- 数据模型：`src/api/shop/shopOrder/model/index.ts`
- 后端参数：`ShopOrderParam.java`
- 后端SQL：`ShopOrderMapper.xml`
