peixue-dev/Archive/[一次性]陪伴员收不到订单问题分析.md

陪伴员收不到订单问题分析报告

📋 问题描述

用户反馈：派单后陪伴员收不到订单

用户疑问：订单状态定义冲突是否是导致陪伴员收不到订单的主要原因？

---

✅ 已验证：订单状态定义没有冲突

根据之前的SQL查询结果（[一次性]订单状态字段定义检查.sql），我们已经确认：

订单状态定义清晰

• pay_status=1, status=0, teacher_id=NULL: 62个订单（已支付待派单）✅
• pay_status=1, status=1, teacher_id=NOT NULL: 192个订单（已派单待接单）✅
• 派单后订单的 status 会正确更新为 1，teacher_id 会正确设置 ✅

结论

订单状态定义没有冲突，不是导致陪伴员收不到订单的原因。

---

🔍 陪伴员待接单查询逻辑分析

后端查询逻辑（TeacherServiceImpl.java）

@Override
public Page<com.peidu.vo.OrderDetailVO> getPendingOrders(Long teacherId, Integer page, Integer size) {
    Page<Order> pageObj = new Page<>(page, size);
    
    LambdaQueryWrapper<Order> wrapper = new LambdaQueryWrapper<>();
    wrapper.eq(Order::getTeacherId, teacherId);     // 分配给我的
    wrapper.eq(Order::getStatus, 1);                // 待接单状态
    wrapper.eq(Order::getPayStatus, 1);             // 已支付
    wrapper.eq(Order::getDeleted, 0);               // 未删除
    wrapper.orderByDesc(Order::getCreateTime);
    
    Page<Order> orderPage = orderMapper.selectPage(pageObj, wrapper);
    // ... 转换为VO
}

查询条件

1. ✅ teacher_id = teacherId - 只查询分配给当前陪伴员的订单
2. ✅ status = 1 - 待接单状态
3. ✅ pay_status = 1 - 已支付
4. ✅ deleted = 0 - 未删除

前端调用逻辑（pending-orders.vue）

const res = await teacherApi.getPendingOrders({
  teacherId: this.teacherId,
  page: this.page,
  size: this.size
})

前端获取teacherId的方式

const userInfo = uni.getStorageSync('userInfo')
this.teacherId = userInfo.teacherId || userInfo.id

---

🎯 可能的原因分析

原因1：teacherId映射关系问题 ⚠️

问题描述：

• 前端从 userInfo 中获取 teacherId
• 但 userInfo 中的 teacherId 可能与数据库中的 teacher.id 不一致

验证方法：

1. 检查 teacher 表中的 user_id 字段是否正确映射到 user 表
2. 检查登录时返回的 userInfo 中的 teacherId 是否正确

SQL验证：

-- 检查陪伴员10096的user_id映射
SELECT 
    t.id as teacher_id,
    t.user_id,
    t.teacher_name,
    u.id as user_table_id,
    u.nickname
FROM teacher t
LEFT JOIN user u ON t.user_id = u.id
WHERE t.id = 10096;

---

原因2：前端未正确获取teacherId ⚠️

问题描述：

• 前端使用 userInfo.teacherId || userInfo.id
• 如果 userInfo 中没有 teacherId 字段，会使用 userInfo.id（这是 user.id，不是 teacher.id）

验证方法：

1. 检查登录接口返回的 userInfo 结构
2. 确认 userInfo 中是否包含正确的 teacherId

可能的问题：

// ❌ 错误：userInfo.id 是 user.id，不是 teacher.id
this.teacherId = userInfo.id

// ✅ 正确：userInfo.teacherId 是 teacher.id
this.teacherId = userInfo.teacherId

---

原因3：派单时未正确设置teacher_id ⚠️

问题描述：

• 管理师派单时，可能未正确设置 teacher_id
• 或者设置的 teacher_id 与陪伴员实际的 teacher.id 不一致

验证方法：

1. 检查派单接口的实现（ManagerController.assignOrder）
2. 查看订单306的 teacher_id 是否正确

SQL验证：

-- 查看订单306的teacher_id
SELECT id, order_no, teacher_id, status, pay_status
FROM `order`
WHERE id = 306;

---

原因4：前端显示逻辑问题 ⚠️

问题描述：

• 后端返回了正确的数据，但前端未正确显示
• 或者前端的刷新机制有问题

验证方法：

1. 检查前端控制台日志，查看API返回的数据
2. 检查前端的数据绑定和渲染逻辑

---

原因5：缓存问题 ⚠️

问题描述：

• 前端或后端可能有缓存，导致数据未及时更新

验证方法：

1. 清除前端缓存（uni.clearStorageSync()）
2. 重启后端服务
3. 重新登录陪伴员账号

---

🔧 排查步骤建议

步骤1：验证订单306的状态

运行SQL查询：

SELECT id, order_no, teacher_id, status, pay_status, deleted
FROM `order`
WHERE id = 306;

预期结果：

• teacher_id = 10096（或其他陪伴员ID）
• status = 1（待接单）
• pay_status = 1（已支付）
• deleted = 0（未删除）

---

步骤2：验证陪伴员的user_id映射

运行SQL查询：

SELECT 
    t.id as teacher_id,
    t.user_id,
    t.teacher_name,
    u.id as user_table_id,
    u.nickname
FROM teacher t
LEFT JOIN user u ON t.user_id = u.id
WHERE t.id = 10096;

预期结果：

• teacher_id 和 user_id 应该正确关联
• user_table_id 应该等于 user_id

---

步骤3：检查前端获取的teacherId

在陪伴员端前端添加日志：

console.log('[待接单] 用户信息:', userInfo)
console.log('[待接单] 陪伴员ID:', this.teacherId)

预期结果：

• userInfo.teacherId 应该等于数据库中的 teacher.id
• 如果 userInfo.teacherId 为空，说明登录接口未返回正确的 teacherId

---

步骤4：检查后端查询结果

在后端添加日志（已有）：

System.out.println("查询到的所有匹配订单数量: " + allMatchingOrders.size());
for (Order order : allMatchingOrders) {
    System.out.println("  订单ID: " + order.getId() + 
                     ", 状态: " + order.getStatus() + 
                     ", 陪伴员ID: " + order.getTeacherId());
}

预期结果：

• 应该能查询到订单306
• 订单306的 teacher_id 应该等于查询参数中的 teacherId

---

步骤5：检查前端API调用

在前端添加日志（已有）：

console.log('[待接单] API响应:', res)
console.log('[待接单] 加载成功, 总数:', this.pendingCount, '当前列表:', this.list.length)

预期结果：

• res.data.records 应该包含订单306
• res.data.total 应该大于0

---

📊 诊断流程图

派单成功（订单306）
    ↓
检查数据库：订单306的teacher_id和status是否正确？
    ↓ 是
检查teacher表：teacher_id和user_id映射是否正确？
    ↓ 是
检查登录接口：返回的userInfo中是否包含正确的teacherId？
    ↓ 是
检查前端：前端获取的teacherId是否正确？
    ↓ 是
检查后端查询：后端能否查询到订单306？
    ↓ 是
检查前端显示：前端能否正确显示订单306？
    ↓ 是
问题解决 ✅

---

🎯 最可能的原因

根据经验判断，最可能的原因是：

1. 前端获取的teacherId不正确 （概率：60%）

• userInfo.teacherId 为空或不正确
• 前端使用了 userInfo.id（user.id）而不是 teacher.id

2. 登录接口未返回teacherId （概率：30%）

• 登录接口只返回了 user 信息，没有返回 teacher 信息
• 需要在登录接口中查询 teacher 表并返回 teacherId

3. 派单时未正确设置teacher_id （概率：10%）

• 派单接口有bug，未正确设置 teacher_id
• 或者设置的 teacher_id 不正确

---

💡 建议的修复方案

方案1：修复登录接口（推荐）

在登录接口中，查询 teacher 表并返回 teacherId：

// 登录成功后，查询teacher信息
Teacher teacher = teacherService.lambdaQuery()
    .eq(Teacher::getUserId, user.getId())
    .one();

if (teacher != null) {
    userInfo.put("teacherId", teacher.getId());
    userInfo.put("teacherName", teacher.getTeacherName());
}

方案2：前端调用专门的接口获取teacherId

在陪伴员端首页加载时，调用接口获取 teacherId：

async getTeacherId() {
  const userInfo = uni.getStorageSync('userInfo')
  const res = await teacherApi.getTeacherInfo({ userId: userInfo.id })
  if (res.code === 200 && res.data) {
    this.teacherId = res.data.teacherId
    // 保存到本地存储
    userInfo.teacherId = res.data.teacherId
    uni.setStorageSync('userInfo', userInfo)
  }
}

方案3：修改前端获取逻辑（临时方案）

如果 userInfo 中确实没有 teacherId，可以先调用接口查询：

async loadTeacherId() {
  const userInfo = uni.getStorageSync('userInfo')
  
  // 如果已有teacherId，直接使用
  if (userInfo.teacherId) {
    this.teacherId = userInfo.teacherId
    return
  }
  
  // 否则，调用接口查询
  const res = await teacherApi.getTeacherIdByUserId({ userId: userInfo.id })
  if (res.code === 200 && res.data) {
    this.teacherId = res.data.teacherId
    // 保存到本地存储
    userInfo.teacherId = res.data.teacherId
    uni.setStorageSync('userInfo', userInfo)
  }
}

---

📝 下一步行动

1. 运行SQL验证脚本

运行 [一次性]验证陪伴员待接单查询.sql 中的所有查询，确认：

• 订单306的状态是否正确
• 陪伴员10096的user_id映射是否正确
• 后端查询逻辑是否能查到订单306

2. 检查前端日志

在陪伴员端打开控制台，查看：

• userInfo 的完整内容
• teacherId 的值
• API返回的数据

3. 检查后端日志

在后端控制台查看：

• getPendingOrders 方法的查询参数
• 查询到的订单数量
• 订单306是否在查询结果中

4. 根据诊断结果选择修复方案

• 如果是 teacherId 映射问题 → 使用方案1或方案2
• 如果是派单问题 → 检查派单接口
• 如果是前端显示问题 → 检查前端渲染逻辑

---

🔍 需要用户提供的信息

为了进一步诊断问题，请用户提供：

1. SQL查询结果：

   • 运行 [一次性]验证陪伴员待接单查询.sql 中的查询1、2、3、6、7
   • 提供查询结果截图或文本

2. 前端控制台日志：

   • 打开陪伴员端的待接单页面
   • 查看控制台输出的日志
   • 提供 [待接单] 相关的所有日志

3. 后端控制台日志：

   • 陪伴员访问待接单页面时
   • 查看后端控制台输出
   • 提供 getPendingOrders 相关的所有日志

4. 登录接口返回的userInfo：

   • 陪伴员登录后
   • 查看 uni.getStorageSync('userInfo') 的内容
   • 提供完整的 userInfo 对象

---

📌 总结

订单状态定义没有冲突，不是导致陪伴员收不到订单的原因。

最可能的原因是前端获取的 teacherId 不正确，或者登录接口未返回 teacherId。

建议先运行SQL验证脚本和检查前端日志，确认具体原因后再选择修复方案。