318 lines
8.1 KiB
Markdown
318 lines
8.1 KiB
Markdown
# 陪伴员待接单问题诊断和解决方案
|
||
|
||
## 📋 问题描述
|
||
|
||
**用户反馈**：管理师派单给陪伴员后,陪伴员在"待接单"页面看不到订单
|
||
|
||
**具体场景**：
|
||
- 管理师在派单页面选择陪伴员(ID=10096)并派单
|
||
- 派单后前端显示"派单成功"
|
||
- 但陪伴员登录后在"待接单"页面看不到这个订单
|
||
|
||
---
|
||
|
||
## 🔍 技术分析
|
||
|
||
### 1. 派单逻辑（ManagerController.assignOrder）
|
||
|
||
**派单时的操作**：
|
||
```java
|
||
// 更新订单信息
|
||
updateWrapper.set(com.peidu.entity.Order::getTeacherId, teacherId) // 设置陪伴员ID
|
||
.set(com.peidu.entity.Order::getStatus, 1); // 设置状态为1(待接单)
|
||
```
|
||
|
||
**预期结果**：
|
||
- `teacher_id = 10096`
|
||
- `status = 1` (待接单)
|
||
- `pay_status = 1` (已支付)
|
||
|
||
### 2. 陪伴员查询逻辑（TeacherServiceImpl.getPendingOrders）
|
||
|
||
**查询条件**：
|
||
```java
|
||
wrapper.eq(Order::getTeacherId, teacherId); // teacher_id = 陪伴员ID
|
||
wrapper.eq(Order::getStatus, 1); // status = 1 (待接单)
|
||
wrapper.eq(Order::getPayStatus, 1); // pay_status = 1 (已支付)
|
||
wrapper.eq(Order::getDeleted, 0); // deleted = 0 (未删除)
|
||
```
|
||
|
||
### 3. 前端获取teacherId的方式
|
||
|
||
**前端代码**（pending-orders.vue）：
|
||
```javascript
|
||
const userInfo = uni.getStorageSync('userInfo')
|
||
// 🔥 关键：优先使用teacherId，如果没有则使用id或userId
|
||
this.teacherId = userInfo.teacherId || userInfo.id || userInfo.userId
|
||
```
|
||
|
||
---
|
||
|
||
## 🎯 可能的原因
|
||
|
||
### 原因1：前端获取的teacherId不正确 ⚠️ (概率70%)
|
||
|
||
**问题描述**：
|
||
- 前端从 `userInfo` 中获取 `teacherId`
|
||
- 如果 `userInfo.teacherId` 为空,会使用 `userInfo.id` (这是 `user.id`,不是 `teacher.id`)
|
||
- 导致查询时使用了错误的ID
|
||
|
||
**验证方法**：
|
||
1. 在陪伴员端打开控制台
|
||
2. 查看日志中的 `[待接单] 陪伴员ID:` 输出
|
||
3. 确认这个ID是否等于数据库中的 `teacher.id`
|
||
|
||
### 原因2：派单时数据库更新失败 ⚠️ (概率20%)
|
||
|
||
**问题描述**：
|
||
- 虽然后端日志显示"派单成功"
|
||
- 但数据库中的 `teacher_id` 和 `status` 可能没有真正更新
|
||
- 这可能是由于MyBatis-Plus的逻辑删除机制导致的
|
||
|
||
**验证方法**：
|
||
运行SQL查询订单306的实际状态
|
||
|
||
### 原因3：登录接口未返回teacherId ⚠️ (概率10%)
|
||
|
||
**问题描述**：
|
||
- 登录接口只返回了 `user` 信息
|
||
- 没有查询 `teacher` 表并返回 `teacherId`
|
||
|
||
**验证方法**：
|
||
查看登录接口的实现,确认是否返回了 `teacherId`
|
||
|
||
---
|
||
|
||
## 🔧 诊断步骤
|
||
|
||
### 步骤1：运行SQL检查订单状态
|
||
|
||
请在数据库中运行以下SQL,并提供查询结果：
|
||
|
||
```sql
|
||
-- 1. 查看最近派单的订单（假设派给了陪伴员ID=10096）
|
||
SELECT
|
||
id,
|
||
order_no,
|
||
teacher_id,
|
||
status,
|
||
pay_status,
|
||
service_date,
|
||
time_slot,
|
||
create_time,
|
||
update_time,
|
||
CASE
|
||
WHEN teacher_id IS NULL THEN '❌ 未分配陪伴员'
|
||
WHEN status != 1 THEN '❌ 状态不是1（待接单）'
|
||
WHEN pay_status != 1 THEN '❌ 未支付'
|
||
ELSE '✅ 符合条件'
|
||
END as check_result
|
||
FROM `order`
|
||
WHERE teacher_id = 10096
|
||
ORDER BY update_time DESC
|
||
LIMIT 10;
|
||
|
||
-- 2. 查看陪伴员10096应该能看到的待接单订单
|
||
SELECT
|
||
id,
|
||
order_no,
|
||
teacher_id,
|
||
status,
|
||
pay_status,
|
||
service_date,
|
||
time_slot,
|
||
create_time,
|
||
update_time
|
||
FROM `order`
|
||
WHERE teacher_id = 10096
|
||
AND status = 1
|
||
AND pay_status = 1
|
||
AND deleted = 0
|
||
ORDER BY create_time DESC;
|
||
|
||
-- 3. 查看teacher表中ID=10096的陪伴员信息
|
||
SELECT
|
||
id as teacher_id,
|
||
user_id,
|
||
name,
|
||
real_name,
|
||
phone,
|
||
audit_status
|
||
FROM teacher
|
||
WHERE id = 10096;
|
||
```
|
||
|
||
### 步骤2：检查前端控制台日志
|
||
|
||
请在陪伴员端执行以下操作：
|
||
|
||
1. 打开微信开发者工具
|
||
2. 切换到"控制台"标签
|
||
3. 清空控制台日志
|
||
4. 进入"待接单"页面
|
||
5. 查看控制台输出,找到以下关键信息：
|
||
- `[待接单] 用户信息:` - 查看完整的 userInfo 对象
|
||
- `[待接单] 陪伴员ID:` - 查看前端获取的 teacherId
|
||
- `[待接单] API响应:` - 查看后端返回的数据
|
||
|
||
### 步骤3：检查后端控制台日志
|
||
|
||
请在后端控制台查看：
|
||
|
||
1. 派单时的日志：
|
||
- `=== 派单接口被调用 ===`
|
||
- `派单前订单信息:`
|
||
- `更新后订单验证:`
|
||
|
||
2. 查询待接单订单时的日志：
|
||
- 查找包含 `getPendingOrders` 的日志
|
||
- 查看查询参数和查询结果
|
||
|
||
---
|
||
|
||
## 💡 临时解决方案
|
||
|
||
如果确认是前端获取 `teacherId` 的问题,可以使用以下临时方案：
|
||
|
||
### 方案A：手动设置teacherId
|
||
|
||
在陪伴员端的 `pending-orders.vue` 中：
|
||
|
||
```javascript
|
||
onLoad() {
|
||
const userInfo = uni.getStorageSync('userInfo')
|
||
|
||
// 🔥 临时方案：手动设置teacherId
|
||
this.teacherId = 10096 // 替换为实际的陪伴员ID
|
||
|
||
console.log('[待接单] 陪伴员ID:', this.teacherId)
|
||
this.loadList()
|
||
}
|
||
```
|
||
|
||
### 方案B：调用接口获取teacherId
|
||
|
||
```javascript
|
||
async loadTeacherId() {
|
||
const userInfo = uni.getStorageSync('userInfo')
|
||
|
||
// 如果已有teacherId，直接使用
|
||
if (userInfo.teacherId) {
|
||
this.teacherId = userInfo.teacherId
|
||
return
|
||
}
|
||
|
||
// 否则，调用接口查询
|
||
try {
|
||
const res = await teacherApi.getTeacherInfo({ userId: userInfo.id })
|
||
if (res.code === 200 && res.data) {
|
||
this.teacherId = res.data.id
|
||
// 保存到本地存储
|
||
userInfo.teacherId = res.data.id
|
||
uni.setStorageSync('userInfo', userInfo)
|
||
}
|
||
} catch (error) {
|
||
console.error('[待接单] 获取teacherId失败:', error)
|
||
}
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
## 🎯 根本解决方案
|
||
|
||
### 方案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
|
||
|
||
**后端新增接口**：
|
||
```java
|
||
@ApiOperation("根据userId获取teacherId")
|
||
@GetMapping("/teacher/getByUserId")
|
||
public Result<Map<String, Object>> getTeacherByUserId(@RequestParam Long userId) {
|
||
Teacher teacher = teacherService.lambdaQuery()
|
||
.eq(Teacher::getUserId, userId)
|
||
.one();
|
||
|
||
if (teacher == null) {
|
||
return Result.error("未找到陪伴员信息");
|
||
}
|
||
|
||
Map<String, Object> data = new HashMap<>();
|
||
data.put("teacherId", teacher.getId());
|
||
data.put("teacherName", teacher.getTeacherName());
|
||
return Result.success(data);
|
||
}
|
||
```
|
||
|
||
**前端调用**：
|
||
```javascript
|
||
async getTeacherId() {
|
||
const userInfo = uni.getStorageSync('userInfo')
|
||
const res = await teacherApi.getTeacherByUserId({ 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检查** - 运行步骤1中的3个SQL查询
|
||
2. **查看前端日志** - 按步骤2的指引查看控制台
|
||
3. **查看后端日志** - 按步骤3的指引查看后端控制台
|
||
|
||
### 根据诊断结果
|
||
|
||
- **如果SQL查询结果显示订单状态正确** → 问题在前端,使用方案A或B
|
||
- **如果SQL查询结果显示订单状态不正确** → 问题在派单逻辑,需要修复派单接口
|
||
- **如果teacher表中没有user_id映射** → 需要修复数据关联
|
||
|
||
---
|
||
|
||
## 🔍 需要用户提供的信息
|
||
|
||
请提供以下信息以便进一步诊断：
|
||
|
||
1. **SQL查询结果**：
|
||
- 查询1的结果（最近派单的订单）
|
||
- 查询2的结果（符合条件的待接单订单）
|
||
- 查询3的结果（陪伴员信息）
|
||
|
||
2. **前端控制台日志**：
|
||
- `[待接单] 用户信息:` 的完整输出
|
||
- `[待接单] 陪伴员ID:` 的值
|
||
- `[待接单] API响应:` 的完整输出
|
||
|
||
3. **后端控制台日志**：
|
||
- 派单时的完整日志
|
||
- 查询待接单订单时的日志
|
||
|
||
---
|
||
|
||
**创建时间**：2026-01-26
|
||
**状态**：等待用户提供诊断信息
|
||
|