不能直接 try-catch 落库，因 send() 默认异步且不开启 publisher confirms，失败不抛异常；须用 aop + confirmcallback 绑定业务上下文并异步落库。
为什么不能直接在 RabbitTemplate.send() 后 try-catch 落库？
因为 RabbitTemplate.send() 默认是异步发送，调用返回不等于消息已到达 Broker；更关键的是，它默认不开启 publisher confirms，网络中断、Broker 不可用等场景下，send() 仍会静默成功返回，根本捕获不到失败。真正能感知发送结果的，只有通过 setConfirmCallback() 或 setReturnCallback() —— 但这两个回调是异步执行、无上下文、无法直接关联原始业务数据的。
如何用 AOP 拦截并绑定业务上下文到 RabbitMQ 发送过程？
核心思路是：在业务方法调用 RabbitTemplate 前，用 ThreadLocal 存储当前消息的元信息（如业务 ID、payload、exchange/routingKey），再通过 AOP 在 send() 调用前后做钩子，把失败回调和这个上下文关联起来。实际操作中建议：
- 定义一个
@SendWithBackup自定义注解，标注在需要落库保底的方法上 - AOP 切点写成
@Around("execution(* org.springframework.amqp.rabbit.core.RabbitTemplate.send(..))")，但必须加条件过滤，否则会拦截所有 send（包括框架内部调用）——推荐用if (ThreadLocalContext.hasCurrentMessage())做守卫 - 在切面中，从 ThreadLocal 取出业务 ID，包装进一个带重试/落库逻辑的
ConfirmCallback实例，再通过RabbitTemplate.invoke()手动设置该 callback（注意：不能直接 set，因为模板是单例，会污染其他线程）
ConfirmCallback 回调里怎么安全落库而不影响主线程？
回调函数运行在线程池（如 SimpleAsyncTaskExecutor）中，不能直接操作事务或依赖 RequestScope Bean。常见错误是回调里直接调用 @Transactional 方法导致事务失效或 NPE。正确做法：
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 落库逻辑必须是无状态的：只接受业务 ID + payload + 错误原因，不依赖任何 HTTP 请求上下文或用户 Session
- 使用
JdbcTemplate或SimpleJdbcInsert直接写库，绕过 JPA/Hibernate 一级缓存和事务代理 - 表结构至少包含：
id（UUID）、business_id、exchange、routing_key、message_body（TEXT）、status（'pending'/'failed'/'sent'）、created_at - 不要在回调里重试发送，只做记录；另起定时任务扫描 status = 'pending' 的记录，按策略重发
为什么不能用 @Retryable 替代 AOP + ConfirmCallback？
@Retryable 作用于方法调用层级，它只能捕获 send() 抛出的异常，而 RabbitMQ 默认配置下，绝大多数发送失败根本不会抛异常。比如：
- Broker 连接断开时，
send()可能走 fallback 到缓存队列，返回成功 - 消息被
mandatory=true且无匹配 queue 时，若没设returnCallback，就静默丢弃 - 网络超时触发的是底层 SocketException，但
RabbitTemplate可能已封装为日志警告而非抛出
只有显式开启 publisher-confirms: true 并配合 ConfirmCallback，才能 100% 捕获“Broker 是否接收成功”这一层结果。AOP 是为了把这层结果和你的业务语义对齐，而不是替代重试机制。
最易被忽略的一点：ConfirmCallback 的执行线程和业务线程完全隔离，ThreadLocal 在回调里是空的——所以必须在 send 前就把上下文序列化进 callback 对象内部，不能指望回调里再取。
