peixue-dev/Archive/[一次性]管理师派单功能修复总结.md

管理师派单功能修复总结

📋 修复内容

修复1：待派单数量统计逻辑

问题： 原来只根据status=0统计待派单数量，没有考虑支付状态和陪伴员分配情况

修复前：

// 待派单订单数（status=0 表示待派单，不限制支付状态）
QueryWrapper<com.peidu.entity.Order> pendingQuery = new QueryWrapper<>();
pendingQuery.eq("status", 0).eq("deleted", 0);
long pendingOrders = orderService.count(pendingQuery);

修复后：

// 待派单订单数（已支付但未分配陪伴员的订单）
QueryWrapper<com.peidu.entity.Order> pendingQuery = new QueryWrapper<>();
pendingQuery.eq("pay_status", 1)  // 已支付
           .isNull("teacher_id")  // 未分配陪伴员
           .eq("deleted", 0);
long pendingOrders = orderService.count(pendingQuery);

修复原因：

• 用户创建订单后：status=0, pay_status=0, teacher_id=null （待支付）
• 用户支付后：status=0, pay_status=1, teacher_id=null （待派单）✅
• 管理师派单后：status=1, pay_status=1, teacher_id=有值 （已派单）

所以待派单应该是：已支付但未分配陪伴员的订单

修复2：已派单数量统计逻辑

问题： 原来根据status=1统计，但如果派单后status没有正确更新，统计就会错误

修复前：

// 已派单订单数（status=1 表示已派单）
QueryWrapper<com.peidu.entity.Order> assignedQuery = new QueryWrapper<>();
assignedQuery.eq("status", 1).eq("deleted", 0);
long assignedOrders = orderService.count(assignedQuery);

修复后：

// 已派单订单数（已分配陪伴员的订单）
QueryWrapper<com.peidu.entity.Order> assignedQuery = new QueryWrapper<>();
assignedQuery.isNotNull("teacher_id")  // 已分配陪伴员
            .eq("deleted", 0);
long assignedOrders = orderService.count(assignedQuery);

修复原因：

• teacher_id是派单的核心标识
• 即使status没有正确更新，只要teacher_id有值，就说明已派单
• 这样统计更可靠

修复3：派单时添加更新时间

问题： 派单时没有更新update_time字段

修复前：

order.setTeacherId(teacherId);
order.setStatus(1); // 1-已接单/已派单

修复后：

order.setTeacherId(teacherId);
order.setStatus(1); // 1-已派单/待接单
order.setUpdateTime(java.time.LocalDateTime.now()); // 更新时间

修复原因：

• update_time用于追踪订单最后修改时间
• 可以用来计算派单响应时间
• 有助于排查问题

修复4：添加派单通知功能

新增功能： 派单成功后，发送通知给陪伴员和家长

实现代码：

// 发送通知给陪伴员
if (teacher != null && teacher.getUserId() != null) {
    notificationService.sendNotification(
        teacher.getUserId(),
        "order",
        "新订单派单通知",
        "您有新的订单被分配，订单号：" + order.getOrderNo() + "，请及时查看并接单。",
        orderId
    );
}

// 发送通知给家长
if (order.getUserId() != null) {
    notificationService.sendOrderAssignNotification(
        order.getUserId(),
        orderId,
        teacherName
    );
}

通知内容：

• 陪伴员收到： "新订单派单通知 - 您有新的订单被分配，订单号：XXX，请及时查看并接单。"
• 家长收到： "订单已派单 - 您的订单已分配给陪伴员XXX"

📊 订单状态流转

正确的订单状态流转

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=有值
   状态：已完成

订单筛选逻辑

待派单筛选：

WHERE pay_status = 1 
  AND teacher_id IS NULL 
  AND deleted = 0

已派单筛选：

WHERE teacher_id IS NOT NULL 
  AND deleted = 0

📝 测试步骤

步骤1：测试待派单统计

1. 创建几个测试订单
2. 支付其中一些订单
3. 访问管理师统计接口：GET /api/manager/statistics?managerId=1
4. 检查返回的pendingOrders数量
5. 运行SQL验证：Archive/[一次性]检查订单派单状态.sql 第2个查询
6. 确认数量一致

预期结果：

• 待派单数量 = 已支付但未分配陪伴员的订单数
• 不包括未支付的订单
• 不包括已派单的订单

步骤2：测试派单功能

1. 选择一个待派单订单（记录订单ID）
2. 运行SQL查看派单前状态：

   SELECT id, order_no, status, teacher_id, update_time 
   FROM `order` WHERE id = <订单ID>;
   

3. 在管理师界面执行派单操作
4. 再次运行SQL查看派单后状态
5. 检查数据库变化：
   • teacher_id 应该有值
   • status 应该变为1
   • update_time 应该更新

预期结果：

派单前：
id=123, status=0, teacher_id=NULL, update_time=2026-01-26 10:00:00

派单后：
id=123, status=1, teacher_id=5, update_time=2026-01-26 14:30:00

步骤3：测试派单通知

1. 派单成功后，查看后端日志
2. 确认日志中有：

   ✅ 已发送派单通知给陪伴员，userId: XXX
   ✅ 已发送派单通知给家长，userId: XXX
   

3. 陪伴员端登录，进入"消息通知"
4. 确认收到"新订单派单通知"
5. 家长端登录，进入"消息通知"
6. 确认收到"订单已派单"通知

预期结果：

• 陪伴员收到通知，内容包含订单号
• 家长收到通知，内容包含陪伴员姓名
• 点击通知可以跳转到订单详情

步骤4：测试订单筛选

1. 在管理师订单列表页面
2. 选择"待派单"筛选
3. 确认只显示已支付但未分配陪伴员的订单
4. 选择"已派单"筛选
5. 确认只显示已分配陪伴员的订单
6. 清除筛选，查看所有订单

预期结果：

• 待派单筛选：只显示pay_status=1 AND teacher_id IS NULL的订单
• 已派单筛选：只显示teacher_id IS NOT NULL的订单
• 筛选切换流畅，数据正确

步骤5：测试统计数据

1. 访问管理师统计接口
2. 检查返回的数据：

   {
     "pendingOrders": 5,      // 待派单
     "assignedOrders": 10,    // 已派单
     "processingOrders": 3,   // 服务中
     "completedOrders": 20,   // 已完成
     "cancelledOrders": 2,    // 已取消
     "activeTeachers": 8,     // 在岗陪伴员
     "totalOrders": 40        // 总订单数
   }
   

3. 运行SQL验证各项数据
4. 确认数据准确

⚠️ 注意事项

1. 陪伴员userId可能为空

问题： 如果陪伴员的user_id字段为空，无法发送通知

检查SQL：

SELECT id, user_id, name, real_name 
FROM teacher 
WHERE audit_status = 1 AND user_id IS NULL;

解决方案：

• 如果发现有陪伴员user_id为空，需要补充数据
• 或者在派单时提示管理师该陪伴员无法接收通知

2. 订单状态可能不一致

问题： 如果之前有订单派单时status没有更新，会导致统计不准

检查SQL：

SELECT id, order_no, status, teacher_id 
FROM `order` 
WHERE teacher_id IS NOT NULL AND status = 0 AND deleted = 0;

解决方案：

• 如果发现有这样的订单，运行修复SQL：

  UPDATE `order` 
  SET status = 1 
  WHERE teacher_id IS NOT NULL AND status = 0 AND deleted = 0;
  

3. 通知发送失败不影响派单

设计： 即使通知发送失败，派单操作仍然成功

原因：

• 派单是核心业务，不能因为通知失败而失败
• 通知失败会记录日志，方便排查
• 可以后续补发通知

📊 修改文件清单

文件	修改内容	行数
peidu/backend/src/main/java/com/peidu/controller/ManagerController.java	修复待派单统计逻辑	95-115
peidu/backend/src/main/java/com/peidu/controller/ManagerController.java	修复已派单统计逻辑	112-115
peidu/backend/src/main/java/com/peidu/controller/ManagerController.java	添加更新时间	471-478
peidu/backend/src/main/java/com/peidu/controller/ManagerController.java	添加派单通知	510-550
Archive/[一次性]检查订单派单状态.sql	创建检查SQL	新建
Archive/[一次性]管理师派单功能修复总结.md	创建修复总结	新建

🎯 预期效果

修复后，管理师派单功能应该：

1. ✅ 统计准确 - 待派单数量正确显示已支付但未分配陪伴员的订单
2. ✅ 状态正确 - 派单后订单status从0变为1，teacher_id有值
3. ✅ 筛选正常 - 可以正确筛选待派单和已派单订单
4. ✅ 通知及时 - 派单后陪伴员和家长都能收到通知
5. ✅ 日志完整 - 派单过程有详细的日志记录，方便排查问题

---

修复完成时间： 2026-01-26

修复人员： Kiro AI

测试状态： ⚠️ 待用户测试验证

下一步：

1. 重启后端服务
2. 测试派单功能
3. 验证通知是否正常发送
4. 检查统计数据是否准确