rabbitmq防漏单需手动ack+幂等+死信队列+超时控制：关闭autoack，业务成功后调basicack；异常时合理nack；配合唯一id幂等、dlx兜底、unacked监控及业务层超时。
RabbitMQ 中实现消费者手动 ACK 确认，核心是关闭自动签收、在业务逻辑成功后显式调用 basicAck，同时配合死信队列和重试控制，才能真正防漏单。自动确认（autoAck=true）下，消息一发出即被删除，哪怕消费端宕机或处理失败，消息也永久丢失——这正是漏单的根源。
配置手动确认模式
Spring Boot 项目中需在配置文件中明确关闭自动签收：
- 设置
spring.rabbitmq.listener.simple.acknowledge-mode=manual - 禁用异常消息自动重回队列：
default-requeue-rejected: false（避免无限重发） - 限制并发与预取数，如
prefetch: 1，确保单条消息未确认前不推送下一条，防止“假消费”
代码中正确执行 ACK
收到消息后，必须在业务逻辑**完全成功执行完毕**后再调用 channel.basicAck()。任何异常、return 提前退出、或未捕获的 RuntimeException 都会导致 ACK 缺失，消息滞留为 Unacked 状态，最终被 RabbitMQ 重新入队。
- 务必用 try-catch 包裹业务逻辑，只在 try 块末尾调用 basicAck
- catch 中不要吞掉异常，应记录日志，并根据情况选择
basicNack(tag, false, false)（丢弃）或basicNack(tag, false, true)（重回队列） - 注意：deliveryTag 是 channel 级别唯一值，必须使用当前 channel 实例调用，不可跨 channel 或复用
配套防漏单关键措施
单靠手动 ACK 不足以防漏单，还需闭环设计：
- 幂等性保障：对订单创建、支付扣款等操作，加唯一业务 ID（如订单号）+ 数据库唯一索引或 Redis setnx，避免重复消费导致重复下单
-
死信队列兜底：配置
x-dead-letter-exchange，让多次重试失败的消息进入死信队列，人工介入或异步补偿 - 消费状态可观测：通过 RabbitMQ Web 控制台关注队列的 Ready（待投递）和 Unacked（已投递未确认）数量；Unacked 持续不降，说明 ACK 缺失或业务卡住
- 超时兜底机制：虽然 RabbitMQ 默认 15 分钟未 ACK 会重发，但建议业务层自身加超时控制（如 CompletableFuture.orTimeout），主动触发失败处理
常见漏单陷阱与规避
很多“看似正常”的代码实际埋着漏单隐患：
- 在 service 层抛出异常但 controller 层 catch 后静默返回——ACK 未发，消息卡在 Unacked，重启后重发，却因没做幂等而重复下单
- 使用异步线程处理消息（如 @Async），主线程 ACK 返回，但子线程实际失败——此时消息已被删，彻底丢失
- 数据库事务提交成功，但后续发短信/写日志失败，未回滚事务也未拒绝消息——造成“业务部分成功、消息却被确认”，状态不一致
真正的防漏单，不是只写一行 basicAck，而是把 ACK 时机、业务原子性、失败重试边界、最终一致性全部串成一条链路。
