xiaoli/peixue-dev

Fork 0

xiaojiang dedaf98ea2 初始化项目：上传完整代码

2026-02-28 17:26:03 +08:00

13 KiB

Raw Blame History

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

📋 检查目的

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

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

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

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检查当前消息通知的分布情况：

-- 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：高优先级（影响核心业务流程）

订单派单通知给陪伴员
- 场景：管理师将订单分配给陪伴员时
- 接收者：被分配的陪伴员
- 内容：您有新的订单被分配，订单号XXX
反馈需修改通知
- 场景：管理师要求陪伴员修改反馈时
- 接收者：陪伴员
- 内容：您提交的XX日期反馈需要修改，请查看审核意见
家长提出疑问通知给陪伴员
- 场景：家长对反馈提出疑问时
- 接收者：陪伴员 + 管理师
- 内容：家长对您的XX日期反馈提出疑问

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

服务即将开始提醒
- 场景：服务时间前1小时
- 接收者：陪伴员 + 家长
- 内容：您的服务将在1小时后开始，请做好准备
每日反馈提交提醒
- 场景：每天服务结束后
- 接收者：陪伴员
- 内容：请及时提交今日的服务反馈
提现审核结果通知
- 场景：提现审核通过/拒绝
- 接收者：陪伴员
- 内容：您的提现申请已审核通过/拒绝

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

工资发放通知
- 场景：工资发放成功
- 接收者：陪伴员
- 内容：您的XX月工资已发放，金额XXX元
系统公告推送
- 场景：发布重要系统公告
- 接收者：所有用户
- 内容：系统公告内容
新订单可接提醒
- 场景：有新订单发布
- 接收者：符合条件的陪伴员
- 内容：有新的订单可接，请及时查看

⚠️ 当前存在的问题

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

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

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

问题： ManagerReminderController.sendReminder() 中获取userId的逻辑有问题 代码位置： peidu/backend/src/main/java/com/peidu/controller/ManagerReminderController.java:203-210 问题代码：

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 - 提现审核通过/拒绝时 状态： ❌ 待补充

📝 建议的修复顺序

第一步：修复权限问题（已完成）
- ✅ 移除notification接口的JWT拦截器排除
- ✅ 修改getCurrentUserId()抛出异常
第二步：修复提醒管理userId问题
- 修改ManagerReminderController.sendReminder()的userId获取逻辑
- 添加日志记录
第三步：补充反馈流程通知
- 在反馈提交时调用通知方法
- 在反馈审核时调用通知方法
- 在家长提出疑问时调用通知方法
- 在管理师回复时调用通知方法
第四步：补充提现审核通知
- 在提现审核通过/拒绝时调用通知方法
第五步：添加定时提醒
- 服务即将开始提醒（定时任务）
- 每日反馈提交提醒（定时任务）

🔍 测试验证方案

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

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

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

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

测试3：验证提醒管理

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

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

检查人员： Kiro AI

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

13 KiB Raw Blame History Unescape Escape