336 lines
9.1 KiB
Markdown
336 lines
9.1 KiB
Markdown
# 管理师派单功能问题分析
|
||
|
||
## 🚨 问题描述
|
||
|
||
1. **待派单数目不对** - 统计的待派单数量与实际不符
|
||
2. **订单状态不对** - 派单前后订单状态一致，都是status=0
|
||
3. **无法通过筛选** - 使用dispatchStatus筛选时无法正确过滤订单
|
||
|
||
## 🔍 问题根源分析
|
||
|
||
### 问题1：待派单数目统计错误
|
||
|
||
**当前逻辑（ManagerController.java 第95-99行）：**
|
||
```java
|
||
// 待派单订单数（status=0 表示待派单，不限制支付状态）
|
||
QueryWrapper<com.peidu.entity.Order> pendingQuery = new QueryWrapper<>();
|
||
pendingQuery.eq("status", 0).eq("deleted", 0);
|
||
long pendingOrders = orderService.count(pendingQuery);
|
||
```
|
||
|
||
**问题：**
|
||
- 只根据`status=0`判断待派单
|
||
- 没有考虑`teacher_id`字段
|
||
- 没有考虑`pay_status`字段
|
||
|
||
**正确的待派单逻辑应该是：**
|
||
```
|
||
待派单 = pay_status=1(已支付) AND teacher_id IS NULL AND deleted=0
|
||
```
|
||
|
||
因为：
|
||
1. 用户创建订单后，订单status=0，pay_status=0（待支付）
|
||
2. 用户支付后，pay_status=1（已支付），但status仍然是0
|
||
3. 管理师派单后，teacher_id有值，status应该变为1
|
||
4. 所以待派单的订单应该是：已支付但未分配陪伴员的订单
|
||
|
||
### 问题2：派单后订单状态不变
|
||
|
||
**当前逻辑（ManagerController.java 第471-472行）：**
|
||
```java
|
||
order.setTeacherId(teacherId);
|
||
order.setStatus(1); // 1-已接单/已派单
|
||
```
|
||
|
||
**问题：**
|
||
虽然代码中设置了`status=1`，但从你的描述来看，派单前后状态一致，说明：
|
||
1. 可能是数据库更新失败
|
||
2. 可能是有其他地方覆盖了状态
|
||
3. 可能是MyBatis-Plus的更新策略问题
|
||
|
||
**需要检查：**
|
||
- Order实体类的`@TableField`注解配置
|
||
- 是否有更新策略导致null值不更新
|
||
- 是否有触发器或其他逻辑修改了状态
|
||
|
||
### 问题3：筛选逻辑不正确
|
||
|
||
**当前逻辑（ManagerController.java 第182-206行）：**
|
||
```java
|
||
// 只查询已支付的订单
|
||
queryWrapper.eq("pay_status", 1);
|
||
|
||
// 添加派单状态过滤
|
||
if ("pending".equals(dispatchStatus)) {
|
||
queryWrapper.isNull("teacher_id"); // 待派单
|
||
} else if ("assigned".equals(dispatchStatus)) {
|
||
queryWrapper.isNotNull("teacher_id"); // 已派单
|
||
}
|
||
```
|
||
|
||
**问题：**
|
||
- 筛选逻辑本身是正确的
|
||
- 但如果派单后`teacher_id`没有正确更新，筛选就会失败
|
||
- 或者如果派单后`status`没有变化，前端可能根据status筛选也会失败
|
||
|
||
## 📊 订单状态流转分析
|
||
|
||
### 当前的订单状态定义
|
||
|
||
根据代码分析，订单状态应该是：
|
||
- `status=0` - 待派单（已支付，未分配陪伴员）
|
||
- `status=1` - 已派单/待接单（已分配陪伴员，陪伴员未接单）
|
||
- `status=2` - 服务中（陪伴员已签到）
|
||
- `status=3` - 已完成
|
||
- `status=4` - 已取消
|
||
|
||
### 正确的订单流转应该是
|
||
|
||
```
|
||
1. 用户创建订单
|
||
↓
|
||
status=0, pay_status=0, teacher_id=null
|
||
|
||
2. 用户支付订单
|
||
↓
|
||
status=0, pay_status=1, teacher_id=null ← 待派单状态
|
||
|
||
3. 管理师派单
|
||
↓
|
||
status=1, pay_status=1, teacher_id=有值 ← 已派单状态
|
||
|
||
4. 陪伴员接单
|
||
↓
|
||
status=1, pay_status=1, teacher_id=有值 ← 待服务状态
|
||
|
||
5. 陪伴员签到
|
||
↓
|
||
status=2, pay_status=1, teacher_id=有值 ← 服务中状态
|
||
|
||
6. 陪伴员签退
|
||
↓
|
||
status=3, pay_status=1, teacher_id=有值 ← 已完成状态
|
||
```
|
||
|
||
## 🔧 修复方案
|
||
|
||
### 修复1：正确统计待派单数量
|
||
|
||
**修改位置：** `ManagerController.java` 第95-99行
|
||
|
||
**修改前：**
|
||
```java
|
||
// 待派单订单数（status=0 表示待派单，不限制支付状态）
|
||
QueryWrapper<com.peidu.entity.Order> pendingQuery = new QueryWrapper<>();
|
||
pendingQuery.eq("status", 0).eq("deleted", 0);
|
||
long pendingOrders = orderService.count(pendingQuery);
|
||
```
|
||
|
||
**修改后：**
|
||
```java
|
||
// 待派单订单数（已支付但未分配陪伴员的订单）
|
||
QueryWrapper<com.peidu.entity.Order> pendingQuery = new QueryWrapper<>();
|
||
pendingQuery.eq("pay_status", 1) // 已支付
|
||
.isNull("teacher_id") // 未分配陪伴员
|
||
.eq("deleted", 0);
|
||
long pendingOrders = orderService.count(pendingQuery);
|
||
```
|
||
|
||
### 修复2：确保派单后状态正确更新
|
||
|
||
**修改位置：** `ManagerController.java` 第470-476行
|
||
|
||
**修改前：**
|
||
```java
|
||
// 更新订单信息
|
||
order.setTeacherId(teacherId);
|
||
order.setStatus(1); // 1-已接单/已派单
|
||
```
|
||
|
||
**修改后：**
|
||
```java
|
||
// 更新订单信息
|
||
order.setTeacherId(teacherId);
|
||
order.setStatus(1); // 1-已派单/待接单
|
||
order.setUpdateTime(java.time.LocalDateTime.now()); // 更新时间
|
||
|
||
// 🔥 添加日志，确认更新前的值
|
||
System.out.println("准备更新订单:");
|
||
System.out.println(" teacherId: " + order.getTeacherId());
|
||
System.out.println(" status: " + order.getStatus());
|
||
System.out.println(" updateTime: " + order.getUpdateTime());
|
||
```
|
||
|
||
### 修复3：添加派单通知
|
||
|
||
**修改位置：** `ManagerController.java` 第510-512行
|
||
|
||
**修改后：**
|
||
```java
|
||
if (updatedOrder.getStatus() == 1) {
|
||
System.out.println("✅ 订单状态更新成功");
|
||
|
||
// 🔥 发送派单通知给陪伴员
|
||
try {
|
||
INotificationService notificationService =
|
||
(INotificationService) SpringContextHolder.getBean("notificationServiceImpl");
|
||
|
||
// 获取陪伴员信息
|
||
Teacher teacher = teacherService.getById(teacherId);
|
||
if (teacher != null && teacher.getUserId() != null) {
|
||
// 发送通知给陪伴员
|
||
notificationService.sendNotification(
|
||
teacher.getUserId(),
|
||
"order",
|
||
"新订单派单通知",
|
||
"您有新的订单被分配，订单号：" + orderId + "，请及时查看并接单。",
|
||
orderId
|
||
);
|
||
System.out.println("✅ 已发送派单通知给陪伴员，userId: " + teacher.getUserId());
|
||
} else {
|
||
System.out.println("⚠️ 陪伴员userId为空，无法发送通知");
|
||
}
|
||
|
||
// 发送通知给家长
|
||
if (order.getUserId() != null) {
|
||
String teacherName = teacher != null ?
|
||
(teacher.getRealName() != null ? teacher.getRealName() : teacher.getName()) :
|
||
"陪伴员";
|
||
notificationService.sendOrderAssignNotification(
|
||
order.getUserId(),
|
||
orderId,
|
||
teacherName
|
||
);
|
||
System.out.println("✅ 已发送派单通知给家长，userId: " + order.getUserId());
|
||
}
|
||
} catch (Exception e) {
|
||
System.out.println("⚠️ 发送派单通知失败: " + e.getMessage());
|
||
e.printStackTrace();
|
||
}
|
||
|
||
return Result.success(true, "派单成功");
|
||
} else {
|
||
System.out.println("❌ 订单状态更新失败，当前状态: " + updatedOrder.getStatus());
|
||
return Result.error("订单状态更新失败");
|
||
}
|
||
```
|
||
|
||
### 修复4：检查Order实体类的更新策略
|
||
|
||
需要检查Order实体类中status字段的配置：
|
||
|
||
```java
|
||
@TableField(updateStrategy = FieldStrategy.NOT_NULL)
|
||
private Integer status;
|
||
```
|
||
|
||
如果配置了`updateStrategy = FieldStrategy.NOT_NULL`，当status为null时不会更新。
|
||
但我们设置的是1，不是null，所以应该没问题。
|
||
|
||
需要检查是否有其他配置影响了更新。
|
||
|
||
## 📝 测试验证步骤
|
||
|
||
### 步骤1：验证待派单统计
|
||
|
||
1. 创建几个测试订单
|
||
2. 支付其中一些订单
|
||
3. 查看管理师统计数据
|
||
4. 确认待派单数量 = 已支付但未分配陪伴员的订单数
|
||
|
||
### 步骤2：验证派单功能
|
||
|
||
1. 选择一个待派单订单
|
||
2. 分配陪伴员
|
||
3. 点击派单
|
||
4. 检查数据库：
|
||
- `teacher_id` 是否有值
|
||
- `status` 是否变为1
|
||
- `update_time` 是否更新
|
||
|
||
### 步骤3：验证派单通知
|
||
|
||
1. 派单成功后
|
||
2. 陪伴员端查看消息通知
|
||
3. 确认收到"新订单派单通知"
|
||
4. 家长端查看消息通知
|
||
5. 确认收到"订单已派单"通知
|
||
|
||
### 步骤4：验证筛选功能
|
||
|
||
1. 使用"待派单"筛选
|
||
2. 确认只显示已支付但未分配陪伴员的订单
|
||
3. 使用"已派单"筛选
|
||
4. 确认只显示已分配陪伴员的订单
|
||
|
||
## 🔍 需要检查的SQL
|
||
|
||
```sql
|
||
-- 1. 查看所有订单的状态分布
|
||
SELECT
|
||
status,
|
||
pay_status,
|
||
CASE
|
||
WHEN teacher_id IS NULL THEN '未分配'
|
||
ELSE '已分配'
|
||
END as teacher_status,
|
||
COUNT(*) as count
|
||
FROM `order`
|
||
WHERE deleted = 0
|
||
GROUP BY status, pay_status, teacher_status
|
||
ORDER BY status, pay_status;
|
||
|
||
-- 2. 查看待派单订单（正确的逻辑）
|
||
SELECT
|
||
id,
|
||
order_no,
|
||
status,
|
||
pay_status,
|
||
teacher_id,
|
||
user_id,
|
||
create_time,
|
||
update_time
|
||
FROM `order`
|
||
WHERE pay_status = 1
|
||
AND teacher_id IS NULL
|
||
AND deleted = 0
|
||
ORDER BY create_time DESC;
|
||
|
||
-- 3. 查看派单后的订单
|
||
SELECT
|
||
id,
|
||
order_no,
|
||
status,
|
||
pay_status,
|
||
teacher_id,
|
||
user_id,
|
||
create_time,
|
||
update_time
|
||
FROM `order`
|
||
WHERE teacher_id IS NOT NULL
|
||
AND deleted = 0
|
||
ORDER BY update_time DESC
|
||
LIMIT 20;
|
||
|
||
-- 4. 检查派单前后的状态变化
|
||
-- 先记录派单前的订单ID和状态
|
||
-- 然后派单
|
||
-- 再查询该订单的状态
|
||
SELECT
|
||
id,
|
||
order_no,
|
||
status,
|
||
teacher_id,
|
||
update_time
|
||
FROM `order`
|
||
WHERE id = <订单ID>;
|
||
```
|
||
|
||
---
|
||
|
||
**分析完成时间：** 2026-01-26
|
||
|
||
**分析人员：** Kiro AI
|
||
|
||
**下一步：** 等待用户确认后开始修复
|