196 lines
4.8 KiB
Markdown
196 lines
4.8 KiB
Markdown
# 待支付状态混淆问题诊断
|
||
|
||
## 问题描述
|
||
|
||
数据库中存在 `status=0` 的订单，但后端代码中 `status=0` 的含义存在**矛盾**。
|
||
|
||
---
|
||
|
||
## 核心矛盾
|
||
|
||
### 1️⃣ 订单状态定义（OrderServiceImpl.java 第760-770行）
|
||
|
||
```java
|
||
/**
|
||
* 订单状态定义：
|
||
* 0 - 待支付：订单已创建，等待支付
|
||
* 1 - 待接单：已支付，等待陪伴员接单
|
||
* 2 - 待服务：已接单，等待签到开始服务
|
||
* 3 - 服务中：已签到，正在服务
|
||
* 4 - 已完成：服务已完成（已签退）
|
||
* -1 - 已取消：用户取消或超时取消
|
||
* -2 - 已退款：退款成功
|
||
*/
|
||
```
|
||
|
||
**注释说明：** `0 = 待支付`
|
||
|
||
---
|
||
|
||
### 2️⃣ 实际代码逻辑
|
||
|
||
#### 订单创建时（OrderServiceImpl.java 第90行）
|
||
```java
|
||
order.setStatus(0); // 待支付
|
||
order.setPayStatus(0); // 未支付
|
||
```
|
||
✅ **符合定义：** 创建订单时 `status=0` 表示待支付
|
||
|
||
---
|
||
|
||
#### 支付成功后（OrderServiceImpl.java 第225行）
|
||
```java
|
||
// 🔥 修复：支付成功后，设置订单状态为待派单
|
||
order.setStatus(0); // 0-待派单（支付完成，等待管理师派单）
|
||
log.info("支付成功，订单状态设置为待派单(status=0)");
|
||
```
|
||
❌ **与定义矛盾：** 支付成功后仍然设置 `status=0`，但注释说是"待派单"
|
||
|
||
---
|
||
|
||
#### 陪伴员拒单后（OrderServiceImpl.java 第863行）
|
||
```java
|
||
// 🔥 修改：拒单后订单状态回到待派单(0)，清除陪伴员ID，让管理师重新分配
|
||
order.setStatus(0); // 0-待派单（回到待分配状态）
|
||
order.setTeacherId(null); // 清除陪伴员ID
|
||
```
|
||
❌ **与定义矛盾：** 拒单后设置 `status=0`，注释说是"待派单"
|
||
|
||
---
|
||
|
||
#### 状态流转规则（OrderServiceImpl.java 第772行）
|
||
```java
|
||
/**
|
||
* 状态流转规则：
|
||
* 0(待支付) -> 1(待接单) [支付成功] | -1(已取消) [取消订单]
|
||
*/
|
||
|
||
case 0: // 待支付
|
||
return to == 1 || to == -1; // 支付成功->待接单 或 取消
|
||
```
|
||
✅ **符合定义：** `status=0` 只能流转到 `1(待接单)` 或 `-1(已取消)`
|
||
|
||
---
|
||
|
||
## 问题根源
|
||
|
||
### 代码中 `status=0` 有**两种含义**：
|
||
|
||
1. **待支付**（订单创建时，未支付）
|
||
- `pay_status = 0`（未支付）
|
||
- 用户还没有付款
|
||
|
||
2. **待派单**（支付成功后，等待管理师派单）
|
||
- `pay_status = 1`（已支付）
|
||
- 用户已经付款，等待管理师分配陪伴员
|
||
|
||
---
|
||
|
||
## 数据库中的实际情况
|
||
|
||
### 可能存在两种 `status=0` 的订单：
|
||
|
||
#### 类型1：真正的待支付订单
|
||
```sql
|
||
status = 0
|
||
pay_status = 0 -- 未支付
|
||
pay_time IS NULL
|
||
```
|
||
|
||
#### 类型2：实际是待派单订单
|
||
```sql
|
||
status = 0
|
||
pay_status = 1 -- 已支付
|
||
pay_time IS NOT NULL
|
||
```
|
||
|
||
---
|
||
|
||
## 验证方法
|
||
|
||
运行以下SQL查询：
|
||
|
||
```sql
|
||
-- 检查status=0的订单，按支付状态分组
|
||
SELECT
|
||
pay_status,
|
||
COUNT(*) as count,
|
||
CASE
|
||
WHEN pay_status = 0 THEN '未支付（真正的待支付）'
|
||
WHEN pay_status = 1 THEN '已支付（实际是待派单）'
|
||
ELSE '其他'
|
||
END as description
|
||
FROM work_order
|
||
WHERE status = 0
|
||
GROUP BY pay_status;
|
||
|
||
-- 查看具体订单
|
||
SELECT
|
||
id,
|
||
order_no,
|
||
status,
|
||
pay_status,
|
||
pay_time,
|
||
teacher_id,
|
||
create_time
|
||
FROM work_order
|
||
WHERE status = 0
|
||
ORDER BY create_time DESC
|
||
LIMIT 20;
|
||
```
|
||
|
||
---
|
||
|
||
## 结论
|
||
|
||
**"待支付"在后端算不算订单状态？**
|
||
|
||
✅ **算！** 但存在设计问题：
|
||
|
||
1. **定义上：** `status=0` 明确定义为"待支付"
|
||
2. **实际使用：** `status=0` 被用于表示两种不同的业务状态
|
||
- 待支付（未付款）
|
||
- 待派单（已付款）
|
||
|
||
3. **区分方式：** 通过 `pay_status` 字段区分
|
||
- `pay_status=0` → 真正的待支付
|
||
- `pay_status=1` → 实际是待派单
|
||
|
||
---
|
||
|
||
## 建议
|
||
|
||
### 方案1：保持现状（需要明确文档）
|
||
- 明确说明 `status=0` 有两种含义
|
||
- 必须结合 `pay_status` 判断实际状态
|
||
|
||
### 方案2：修改状态定义（推荐）
|
||
```
|
||
0 - 待支付（未付款）
|
||
1 - 待派单（已付款，等待管理师派单）
|
||
2 - 待接单（已派单，等待陪伴员接单）
|
||
3 - 待服务（已接单，等待签到）
|
||
4 - 服务中（已签到）
|
||
5 - 已完成（已签退）
|
||
-1 - 已取消
|
||
-2 - 已退款
|
||
```
|
||
|
||
这样每个状态都有明确的业务含义，不会混淆。
|
||
|
||
---
|
||
|
||
## 当前状态总结
|
||
|
||
| 状态值 | 注释定义 | 实际使用场景1 | 实际使用场景2 | 区分字段 |
|
||
|--------|----------|---------------|---------------|----------|
|
||
| 0 | 待支付 | 订单创建，未支付 | 支付成功，待派单 | pay_status |
|
||
| 1 | 待接单 | 已派单，等待陪伴员接单 | - | - |
|
||
| 2 | 待服务 | 已接单，等待签到 | - | - |
|
||
| 3 | 服务中 | 已签到，正在服务 | - | - |
|
||
| 4 | 已完成 | 服务完成 | - | - |
|
||
| -1 | 已取消 | 订单取消 | - | - |
|
||
| -2 | 已退款 | 订单退款 | - | - |
|
||
|
||
**关键点：** `status=0` 是唯一一个需要结合 `pay_status` 才能确定真实业务状态的值！
|