必须先调用channel.confirmSelect()开启确认模式，否则waitForConfirms()始终返回true却无实际确认；需手动控制批次边界并及时调用waitForConfirms()实现批量确认，而非依赖不存在的setConfirmBatchSize()等伪配置。
批量确认必须先开启 confirmSelect()
不调用 channel.confirmSelect()，后续所有 waitForConfirms() 调用都会直接返回 true，看似“成功”，实则完全没走确认流程。这是最常被忽略的前置条件。Java 客户端不会报错，但你的消息可靠性形同虚设。
waitForConfirms() 是同步阻塞点，必须按批次边界调用
批量确认不是靠自动聚合，而是靠你手动控制调用时机。典型做法是每发 N 条（比如 100 条）后立即调用一次 waitForConfirms()。它会阻塞，直到 Broker 返回这批消息的整体确认结果（ack 或 nack）。
- 如果返回
false，说明整批至少有一条失败，你需要重发全部 —— 这是批量确认的代价 - 不能只在循环末尾调一次，否则就退化成单次大批次，超时风险高、失败成本极高
- 批次大小（如 50/100/200）需权衡：太小 → 阻塞频繁；太大 → 失败重传开销大、内存占用高
batchSize 不是 RabbitMQ 的内置配置项，别被误导
知识库中提到的 channel.setConfirmBatchSize() 并非标准 Java 客户端 API（AMQP Client 5.x 不支持），属于混淆或过时封装。真实批量逻辑完全由你控制发送节奏 + 手动调用 waitForConfirms() 实现。
常见错误包括：
立即学习“Java免费学习笔记（深入）”；
- 误以为设置了某个参数就自动批量，结果仍为单条确认
- 把消费者端的
prefetch或 Spring 的batch-size当作生产者批量确认配置 - 未捕获
IOException或超时异常，导致线程卡死或静默失败
异步确认才是高吞吐场景的合理选择
如果你追求真正高性能且不能接受整批重发，waitForConfirms() 批量模式只是过渡方案。应转向异步确认：channel.addConfirmListener() + ConcurrentSkipListMap 维护待确认消息，实现细粒度失败重试。批量确认只适合对失败容忍度较高、消息价值中等、且希望快速落地的场景。
真正难的是失败定位与幂等重发设计 —— 批量确认把“哪条错了”这个信息丢掉了，你得靠业务 ID、日志上下文或本地缓存来补全。
