405 lines
11 KiB
Markdown
405 lines
11 KiB
Markdown
# 陪伴员收不到订单问题分析报告
|
||
|
||
## 📋 问题描述
|
||
**用户反馈**：派单后陪伴员收不到订单
|
||
|
||
**用户疑问**：订单状态定义冲突是否是导致陪伴员收不到订单的主要原因？
|
||
|
||
---
|
||
|
||
## ✅ 已验证：订单状态定义没有冲突
|
||
|
||
根据之前的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）
|
||
|
||
```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）
|
||
|
||
```javascript
|
||
const res = await teacherApi.getPendingOrders({
|
||
teacherId: this.teacherId,
|
||
page: this.page,
|
||
size: this.size
|
||
})
|
||
```
|
||
|
||
### 前端获取teacherId的方式
|
||
|
||
```javascript
|
||
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验证**：
|
||
```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`
|
||
|
||
**可能的问题**：
|
||
```javascript
|
||
// ❌ 错误：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验证**：
|
||
```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查询：
|
||
```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查询：
|
||
```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
|
||
在陪伴员端前端添加日志：
|
||
```javascript
|
||
console.log('[待接单] 用户信息:', userInfo)
|
||
console.log('[待接单] 陪伴员ID:', this.teacherId)
|
||
```
|
||
|
||
**预期结果**：
|
||
- `userInfo.teacherId` 应该等于数据库中的 `teacher.id`
|
||
- 如果 `userInfo.teacherId` 为空，说明登录接口未返回正确的 `teacherId`
|
||
|
||
---
|
||
|
||
### 步骤4：检查后端查询结果
|
||
在后端添加日志（已有）：
|
||
```java
|
||
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调用
|
||
在前端添加日志（已有）：
|
||
```javascript
|
||
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`：
|
||
|
||
```java
|
||
// 登录成功后，查询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`：
|
||
|
||
```javascript
|
||
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`，可以先调用接口查询：
|
||
|
||
```javascript
|
||
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验证脚本和检查前端日志，确认具体原因后再选择修复方案。
|