rabbitmq仅负责可靠投递，高内聚事件模型需java层抽象+spring生命周期管理+显式边界控制；须封装rabbittemplate、分层解耦@eventlistener与@rabbitlistener、落地事件状态机。
直接说结论：RabbitMQ 本身不提供“高内聚”的事件模型，它只负责可靠投递；所谓高内聚，必须靠 Java 层的事件抽象 + Spring 的生命周期管理 + 显式边界控制来实现，否则容易滑向“消息泛滥、职责模糊、调试困难”的陷阱。
避免把 RabbitTemplate 当成万能事件总线
很多团队一上来就用 RabbitTemplate.convertAndSend() 到处发消息，结果很快出现三类问题：业务语义丢失（比如都往 "event.queue" 里塞不同结构的 JSON）、监听器无法区分关注点、测试时不得不启动 RabbitMQ 才能跑通单元测试。
- 真正高内聚的做法是：每个业务域定义自己的事件类（如
UserRegisteredEvent），且只允许通过专用发布器（如UserEventPublisher）发出 -
RabbitTemplate仅作为底层传输适配器，不出现在 service 或 controller 层；它的使用被严格封装在 infrastructure 包下 - 禁止在监听器方法里直接调用
repository.save()等强副作用操作——应转为调用领域服务，由后者统一处理事务与状态校验
用 @EventListener + @RabbitListener 分层解耦
Spring 的 @EventListener 和 RabbitMQ 的 @RabbitListener 容易混淆，但它们定位完全不同：@EventListener 是 JVM 内存级事件，适合轻量通知（如缓存刷新）；@RabbitListener 是跨进程事件，必须用于需要持久化、重试、跨服务的场景。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 用户注册成功后，先发一个
@EventListener触发本地 token 清理，再发一个RabbitTemplate消息触发短信发送——前者快且无依赖，后者带重试保障 - 不要在一个
@RabbitListener方法里同时处理“发短信”和“写日志表”，应拆成两个独立消费者，各自绑定不同 queue - 若需保证顺序（如订单创建 → 支付成功 → 发货），别依赖单个 queue 的 FIFO，而要用 routing key + exclusive consumer + 幂等键（如
order_id）组合控制
事件状态机必须显式落地，不能只靠 MQ ACK
RabbitMQ 的消息确认（ACK）只管“有没有被消费者收到”，不管“事件有没有被正确处理”。你看到 RECEIVED 状态，不代表业务逻辑已执行成功——这正是很多线上故障的根源。
- 每个关键事件类型（如
OrderCreatedEvent）对应一张状态表，字段至少含：event_id、status（NEW/PUBLISHED/PROCESSED/FAILED）、retry_count、last_error - 监听器入口第一行就应更新该记录为
PUBLISHED；处理成功后再设为PROCESSED；失败则捕获异常并设为FAILED，同时触发告警 - 定时任务每 5 分钟扫描
status = 'FAILED'且retry_count 的记录，重新投递到死信队列或原 queue（加延时 header）
最常被忽略的一点：事件命名不是技术活，而是领域建模活。写 "user.event" 不如写 "UserEmailVerified"；发消息前不校验 email != null，比选错 exchange 类型更容易导致下游崩溃。内聚性不在代码结构里，而在每个事件是否真实表达了“某人在某时做了某件有业务意义的事”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
