若WorkBuddy安装后无通知，需依次排查：一、确认RabbitMQ服务运行及5672端口监听；二、校验application.yml与RabbitMQ的vhost、用户名、密码及权限一致性；三、检查workbuddy.notify.exchange声明、notify队列持久化及绑定关系；四、验证NotifyConsumer是否启动并正常消费；五、通过RabbitMQ界面发布测试消息并获取，定位问题在消息通路或通知网关环节。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
如果您已完成WorkBuddy安装，但任务完成、审批变更等事件发生后仍无通知送达，则很可能是本地消息队列服务未启动或与通知模块通信异常。以下是针对性排查步骤：
一、确认本地RabbitMQ服务是否运行并监听正确端口
RabbitMQ是WorkBuddy默认依赖的消息中间件，负责在任务引擎与通知模块间异步传递事件。若服务未运行、端口被占用或配置错配，通知将无法入队或出队。
1、在终端执行命令：sudo systemctl status rabbitmq-server（Linux）或检查Windows服务列表中“RabbitMQ”状态是否为“正在运行”。
2、若服务未运行，执行：sudo systemctl start rabbitmq-server 并等待3秒后再次检查状态。
3、验证5672端口是否被监听：执行 netstat -tuln | grep :5672（Linux/macOS）或 netstat -ano | findstr :5672（Windows），确认输出含LISTENING且PID对应rabbitmq进程。
4、若端口被占用，需终止冲突进程或修改WorkBuddy配置文件中mq.host与mq.port指向备用端口，并同步更新RabbitMQ的advanced.config。
二、校验WorkBuddy与RabbitMQ的认证凭据一致性
WorkBuddy通过预设的vhost、用户名和密码连接RabbitMQ，任意一项不匹配均导致连接拒绝，日志中通常表现为“ACCESS_REFUSED”错误。
1、打开WorkBuddy安装目录下的config/application.yml，定位spring.rabbitmq区块，记录virtual-host、username、password值。
2、登录RabbitMQ管理界面（默认http://localhost:15672，使用guest/guest登录），进入Admin → Virtual Hosts，确认所配置的vhost已存在且状态为“running”。
3、进入Admin → Users，点击对应用户名，检查其“Tags”是否包含management，“Permissions”中该vhost的“Configure / Write / Read”三项权限均为“.*”。
4、若凭据不一致，需在RabbitMQ中创建匹配用户并赋权，或修改WorkBuddy配置后重启服务。
三、检查消息队列绑定关系与交换器声明
WorkBuddy依赖特定Exchange（如workbuddy.notify.exchange）和Queue（如notify.email.queue）完成路由。若交换器未声明、绑定缺失或队列持久化失败，消息将直接丢弃。
1、在RabbitMQ管理界面，进入Exchanges标签页，搜索workbuddy.notify.exchange，确认Type为topic且State为“Ready”。
WorkBuddy 桌宠工厂 —— 给一张角色图、一个 codex.pet 链接、一条 codex-pets.net 下载 URL、或一份现成的精灵表，就能自动创建一只可联动 WorkBuddy 状态的桌面宠物。当用户说"创建桌宠"、"做一只桌宠"、"用这张图做桌宠"、"从 codex.pet 安装桌宠"、"导入 codex 桌宠 XX"、"装一下 codex-pets.net 上的 XX&quo
2、进入Queues标签页，搜索notify.前缀队列，确认其Auto-delete为false、Durable为true。
3、点击任一notify队列，切换至Bindings子页，确认已绑定至workbuddy.notify.exchange，且Routing key为notify.#。
4、若缺失，需手动添加绑定；若队列不存在，重启WorkBuddy客户端，观察其是否自动声明——若未自动创建，说明spring.rabbitmq.listener.simple.missing-queues-fatal设为false或初始化逻辑被跳过。
四、验证通知消费者进程是否激活并处于活跃消费状态
即使消息成功入队，若WorkBuddy内部的NotifyConsumer未启动或因异常停止，队列中的消息将长期积压，不会触发实际发送动作。
1、在WorkBuddy主界面右下角系统托盘图标上右键，选择“显示日志窗口”，筛选关键词NotifyConsumer或SimpleMessageListenerContainer。
2、查找类似日志："Started container for queue(s): [notify.email.queue]"，确认无Failed to check queues或Consumer failed, channel closed报错。
3、若日志中无启动记录，进入config/application.yml，确认spring.rabbitmq.listener.simple.auto-startup值为true。
4、修改后保存配置，执行WorkBuddy.exe --restart-service（Windows）或./workbuddy.sh restart（Linux/macOS）强制重载监听器。
五、抓包验证消息是否实际发布至Exchange
当以上环节均正常但通知仍不发出时，需确认事件是否真正到达RabbitMQ层，排除WorkBuddy业务逻辑层提前拦截或过滤的可能。
1、在RabbitMQ管理界面，进入目标Exchange详情页，点击“Publish message”按钮。
2、填写Routing key为notify.email.task.completed，Payload输入JSON：{"to":"test@domain.com","subject":"Test","body":"OK"}，点击Publish。
3、立即切换至对应Queue的“Get Messages”页，设置Count=1、Acknowledge mode为“Requeue false”，点击获取。
4、若消息成功获取且内容完整，说明队列通路正常，问题位于WorkBuddy通知模板渲染或邮件/短信网关调用环节；若获取失败，说明Exchange未正确绑定或Publish操作未命中路由规则。
