peixue-dev/Archive/[一次性]陪伴员消息通知联通检查报告.md

# 陪伴员消息通知联通检查报告

## 📋 检查目的

检查陪伴员端还有哪些消息通知功能没有和其他端（管理师、家长等）联通，确保消息能够正确地在不同角色之间流转。

## 🔍 系统中已实现的消息通知类型

根据代码分析，系统已经定义了以下消息通知场景：

### 1️⃣ 订单相关通知（Order）

| 通知类型 | 发送对象 | 触发场景 | 实现状态 | 联通状态 |
|---------|---------|---------|---------|---------|
| 订单创建 | 家长 | 创建订单成功 | ✅ 已实现 | ✅ 已联通 |
| 订单派单 | 家长 | 管理师分配陪伴员 | ✅ 已实现 | ⚠️ 需确认 |
| 订单接单 | 家长 | 陪伴员接受订单 | ✅ 已实现 | ✅ 已联通 |
| 订单取消 | 家长 + 陪伴员 | 订单被取消 | ✅ 已实现 | ✅ 已联通 |
| 订单完成 | 家长 | 订单自动确认完成 | ✅ 已实现 | ✅ 已联通 |
| 支付成功 | 家长 | 订单支付成功 | ✅ 已实现 | ✅ 已联通 |
| 退款成功 | 家长 | 订单退款成功 | ✅ 已实现 | ✅ 已联通 |

**陪伴员端缺失的订单通知：**
- ❌ **新订单通知**：当有新订单可接时，陪伴员应该收到通知
- ❌ **订单派单通知**：当管理师将订单分配给陪伴员时，陪伴员应该收到通知
- ❌ **订单即将开始提醒**：服务时间前1小时提醒陪伴员

### 2️⃣ 服务相关通知（Service）

| 通知类型 | 发送对象 | 触发场景 | 实现状态 | 联通状态 |
|---------|---------|---------|---------|---------|
| 服务开始（签到） | 家长 | 陪伴员签到 | ✅ 已实现 | ✅ 已联通 |
| 服务结束（签退） | 家长 | 陪伴员签退 | ✅ 已实现 | ✅ 已联通 |
| 服务提醒 | 家长 | 服务时间前提醒 | ✅ 已实现 | ⚠️ 需确认 |

**陪伴员端缺失的服务通知：**
- ❌ **服务即将开始提醒**：服务时间前提醒陪伴员准备
- ❌ **签退提醒**：服务结束时提醒陪伴员签退
- ❌ **超时服务提醒**：服务超过预定时间时提醒

### 3️⃣ 反馈相关通知（Feedback）

| 通知类型 | 发送对象 | 触发场景 | 实现状态 | 联通状态 |
|---------|---------|---------|---------|---------|
| 每日反馈提交 | 家长 | 陪伴员提交每日反馈 | ✅ 已实现 | ⚠️ 需确认 |
| 周反馈提交 | 家长 | 陪伴员提交周反馈 | ✅ 已实现 | ⚠️ 需确认 |
| 月反馈提交 | 家长 | 陪伴员提交月反馈 | ✅ 已实现 | ⚠️ 需确认 |
| 反馈需修改 | 陪伴员 | 管理师要求修改反馈 | ✅ 已实现 | ❌ 未联通 |
| 反馈审核通过 | 家长 | 管理师审核通过反馈 | ✅ 已实现 | ❌ 未联通 |
| 家长提出疑问 | 管理师 | 家长对反馈提出疑问 | ✅ 已实现 | ❌ 未联通 |
| 问题已解决 | 家长 | 管理师解决家长疑问 | ✅ 已实现 | ❌ 未联通 |
| 管理师回复反馈 | 家长/陪伴员 | 管理师回复反馈 | ✅ 已实现 | ❌ 未联通 |

**陪伴员端缺失的反馈通知：**
- ❌ **反馈需修改通知**：管理师要求修改反馈时，陪伴员应该收到通知
- ❌ **反馈审核通过通知**：反馈审核通过后，陪伴员应该收到确认通知
- ❌ **家长提出疑问通知**：家长对反馈提出疑问时，陪伴员应该收到通知
- ❌ **管理师回复通知**：管理师回复反馈时，陪伴员应该收到通知
- ❌ **反馈提交提醒**：每天提醒陪伴员提交当日反馈

### 4️⃣ 提醒管理通知（Reminder）

| 通知类型 | 发送对象 | 触发场景 | 实现状态 | 联通状态 |
|---------|---------|---------|---------|---------|
| 管理师发送提醒 | 所有陪伴员 | 管理师在提醒管理中发送 | ✅ 已实现 | ⚠️ 有问题 |

**当前问题：**
- ⚠️ 管理师发送提醒时，使用的是`teacher.getUserId()`，如果为null则使用`teacher.getId()`，可能导致消息发送给错误的用户
- ⚠️ 提醒管理接口被排除在JWT拦截器之外，存在安全隐患

### 5️⃣ 优惠券通知（Coupon）

| 通知类型 | 发送对象 | 触发场景 | 实现状态 | 联通状态 |
|---------|---------|---------|---------|---------|
| 优惠券领取成功 | 用户 | 领取优惠券 | ✅ 已实现 | ❌ 未调用 |
| 优惠券即将到期 | 用户 | 优惠券3天后到期 | ✅ 已实现 | ❌ 未调用 |
| 优惠券已过期 | 用户 | 优惠券过期 | ✅ 已实现 | ❌ 未调用 |
| 新优惠券上架 | 用户 | 新优惠券上架 | ✅ 已实现 | ❌ 未调用 |

**陪伴员端缺失的优惠券通知：**
- ❌ 所有优惠券通知都未在业务代码中调用

### 6️⃣ 系统通知（System）

| 通知类型 | 发送对象 | 触发场景 | 实现状态 | 联通状态 |
|---------|---------|---------|---------|---------|
| 系统公告 | 所有用户 | 发布系统公告 | ✅ 已实现 | ❌ 未调用 |
| 账户余额变动 | 用户 | 余额增加/减少 | ✅ 已实现 | ❌ 未调用 |
| 积分变动 | 用户 | 积分增加/减少 | ✅ 已实现 | ❌ 未调用 |
| 提现审核结果 | 陪伴员 | 提现审核通过/拒绝 | ✅ 已实现 | ❌ 未调用 |

**陪伴员端缺失的系统通知：**
- ❌ **提现审核结果通知**：陪伴员提现审核后应该收到通知
- ❌ **工资发放通知**：工资发放后应该收到通知
- ❌ **系统公告通知**：重要系统公告应该推送给陪伴员

## 🔄 消息流转分析

### 当前消息流转路径

```
1. 订单流程：
   家长创建订单 → 家长收到"订单创建"通知
   管理师派单 → 家长收到"订单派单"通知 ❌ 陪伴员未收到通知
   陪伴员接单 → 家长收到"陪伴员接单"通知 ❌ 陪伴员未收到确认通知
   陪伴员签到 → 家长收到"服务开始"通知
   陪伴员签退 → 家长收到"服务结束"通知

2. 反馈流程：
   陪伴员提交反馈 → 家长收到"收到新反馈"通知
   管理师审核反馈 → ❌ 陪伴员未收到审核结果通知
   家长提出疑问 → 管理师收到"家长提出疑问"通知 ❌ 陪伴员未收到通知
   管理师回复疑问 → 家长收到"问题已解决"通知 ❌ 陪伴员未收到通知

3. 提醒流程：
   管理师发送提醒 → 所有陪伴员收到提醒 ⚠️ 但可能发送给错误的用户
```

### 缺失的消息流转

```
❌ 陪伴员端缺失的消息流转：

1. 订单相关：
   - 新订单可接 → 陪伴员应该收到通知
   - 订单被派单 → 陪伴员应该收到通知
   - 订单即将开始 → 陪伴员应该收到提醒

2. 反馈相关：
   - 反馈需修改 → 陪伴员应该收到通知
   - 反馈审核通过 → 陪伴员应该收到通知
   - 家长提出疑问 → 陪伴员应该收到通知
   - 管理师回复 → 陪伴员应该收到通知
   - 每日反馈提醒 → 陪伴员应该收到提醒

3. 财务相关：
   - 提现审核结果 → 陪伴员应该收到通知
   - 工资发放 → 陪伴员应该收到通知

4. 系统相关：
   - 系统公告 → 陪伴员应该收到通知
   - 账户变动 → 陪伴员应该收到通知
```

## 📊 数据库检查SQL

运行以下SQL检查当前消息通知的分布情况：

```sql
-- 1. 查看各用户角色的消息数量
SELECT 
    n.user_id,
    u.role,
    u.nickname,
    COUNT(*) as total_count,
    SUM(CASE WHEN n.is_read = 0 THEN 1 ELSE 0 END) as unread_count
FROM notification n
LEFT JOIN user u ON n.user_id = u.id
WHERE n.deleted = 0
GROUP BY n.user_id, u.role, u.nickname
ORDER BY total_count DESC;

-- 2. 查看各类型消息的数量分布
SELECT 
    type,
    COUNT(*) as count,
    SUM(CASE WHEN is_read = 0 THEN 1 ELSE 0 END) as unread_count
FROM notification
WHERE deleted = 0
GROUP BY type
ORDER BY count DESC;

-- 3. 查看陪伴员收到的消息类型
SELECT 
    n.type,
    COUNT(*) as count,
    GROUP_CONCAT(DISTINCT n.title) as titles
FROM notification n
INNER JOIN teacher t ON n.user_id = t.user_id
WHERE n.deleted = 0
GROUP BY n.type
ORDER BY count DESC;

-- 4. 查看最近7天的消息创建情况
SELECT 
    DATE(create_time) as date,
    type,
    COUNT(*) as count
FROM notification
WHERE deleted = 0 
  AND create_time >= DATE_SUB(NOW(), INTERVAL 7 DAY)
GROUP BY DATE(create_time), type
ORDER BY date DESC, count DESC;

-- 5. 检查是否有陪伴员没有收到任何消息
SELECT 
    t.id as teacher_id,
    t.user_id,
    t.name,
    t.real_name,
    COUNT(n.id) as notification_count
FROM teacher t
LEFT JOIN notification n ON t.user_id = n.user_id AND n.deleted = 0
WHERE t.audit_status = 1
GROUP BY t.id, t.user_id, t.name, t.real_name
HAVING notification_count = 0;
```

## 🎯 需要补充的功能

### 优先级1：高优先级（影响核心业务流程）

1. **订单派单通知给陪伴员**
   - 场景：管理师将订单分配给陪伴员时
   - 接收者：被分配的陪伴员
   - 内容：您有新的订单被分配，订单号XXX

2. **反馈需修改通知**
   - 场景：管理师要求陪伴员修改反馈时
   - 接收者：陪伴员
   - 内容：您提交的XX日期反馈需要修改，请查看审核意见

3. **家长提出疑问通知给陪伴员**
   - 场景：家长对反馈提出疑问时
   - 接收者：陪伴员 + 管理师
   - 内容：家长对您的XX日期反馈提出疑问

### 优先级2：中优先级（提升用户体验）

4. **服务即将开始提醒**
   - 场景：服务时间前1小时
   - 接收者：陪伴员 + 家长
   - 内容：您的服务将在1小时后开始，请做好准备

5. **每日反馈提交提醒**
   - 场景：每天服务结束后
   - 接收者：陪伴员
   - 内容：请及时提交今日的服务反馈

6. **提现审核结果通知**
   - 场景：提现审核通过/拒绝
   - 接收者：陪伴员
   - 内容：您的提现申请已审核通过/拒绝

### 优先级3：低优先级（锦上添花）

7. **工资发放通知**
   - 场景：工资发放成功
   - 接收者：陪伴员
   - 内容：您的XX月工资已发放，金额XXX元

8. **系统公告推送**
   - 场景：发布重要系统公告
   - 接收者：所有用户
   - 内容：系统公告内容

9. **新订单可接提醒**
   - 场景：有新订单发布
   - 接收者：符合条件的陪伴员
   - 内容：有新的订单可接，请及时查看

## ⚠️ 当前存在的问题

### 问题1：消息通知接口权限问题（已修复）

**问题：** `/api/notification/**` 被排除在JWT拦截器之外
**影响：** 所有用户看到相同的消息列表
**状态：** ✅ 已修复

### 问题2：提醒管理userId获取问题（待修复）

**问题：** `ManagerReminderController.sendReminder()` 中获取userId的逻辑有问题
**代码位置：** `peidu/backend/src/main/java/com/peidu/controller/ManagerReminderController.java:203-210`
**问题代码：**
```java
for (Teacher teacher : teachers) {
    if (teacher.getUserId() != null) {
        userIds.add(teacher.getUserId());
    } else if (teacher.getId() != null) {
        userIds.add(teacher.getId());  // ⚠️ 可能发送给错误的用户
    }
}
```
**影响：** 当teacher.userId为null时，使用teacher.id作为userId，可能导致消息发送给错误的用户
**状态：** ⚠️ 待修复

### 问题3：反馈流程通知未调用（待补充）

**问题：** 虽然定义了反馈相关的通知方法，但在业务代码中未调用
**影响：** 陪伴员和家长无法及时收到反馈相关的通知
**需要补充的调用位置：**
- `GrowthRecordServiceImpl` - 反馈提交、审核、修改时
- `ManagerFeedbackController` - 管理师回复反馈时
**状态：** ❌ 待补充

### 问题4：提现审核通知未调用（待补充）

**问题：** 定义了提现审核通知方法，但未在提现审核流程中调用
**影响：** 陪伴员无法及时知道提现审核结果
**需要补充的调用位置：**
- `WithdrawController` 或 `WithdrawService` - 提现审核通过/拒绝时
**状态：** ❌ 待补充

## 📝 建议的修复顺序

1. **第一步：修复权限问题**（已完成）
   - ✅ 移除notification接口的JWT拦截器排除
   - ✅ 修改getCurrentUserId()抛出异常

2. **第二步：修复提醒管理userId问题**
   - 修改`ManagerReminderController.sendReminder()`的userId获取逻辑
   - 添加日志记录

3. **第三步：补充反馈流程通知**
   - 在反馈提交时调用通知方法
   - 在反馈审核时调用通知方法
   - 在家长提出疑问时调用通知方法
   - 在管理师回复时调用通知方法

4. **第四步：补充提现审核通知**
   - 在提现审核通过/拒绝时调用通知方法

5. **第五步：添加定时提醒**
   - 服务即将开始提醒（定时任务）
   - 每日反馈提交提醒（定时任务）

## 🔍 测试验证方案

### 测试1：验证消息按用户隔离

1. 使用陪伴员A登录，查看消息列表
2. 使用陪伴员B登录，查看消息列表
3. 确认两个陪伴员看到的消息不同

### 测试2：验证反馈流程通知

1. 陪伴员提交反馈 → 家长应该收到通知
2. 管理师审核反馈 → 陪伴员应该收到通知
3. 家长提出疑问 → 陪伴员和管理师应该收到通知
4. 管理师回复疑问 → 家长和陪伴员应该收到通知

### 测试3：验证提醒管理

1. 管理师发送提醒 → 所有陪伴员应该收到通知
2. 检查数据库确认userId正确

---

**检查完成时间：** 2026-01-26

**检查人员：** Kiro AI

**下一步行动：** 等待用户确认修复范围和优先级