Go中channel.Confirm必须在首次basicPublish前调用，否则确认静默失效；需先ch.Confirm(false)再publish，false禁用multiple ack更安全；无setConfirmBatchSize API，批量靠手动攒批+waitForConfirms或NotifyPublish聚合实现；回调中禁止阻塞操作。
Go 中 channel.Confirm 必须在 basicPublish 前调用，否则确认失效
很多 go 项目在压测时发现 notifypublish 没有回调、waitforconfirms 总是超时，根本原因常是漏掉这步：必须在第一次 basicpublish 之前调用 ch.confirm(false)。一旦 channel 开始发消息，再调就无效——而且不会报错，静默降级为无确认模式。
常见错误写法：
ch, _ := conn.Channel() ch.Publish(...) // ← 先发了！ ch.Confirm(false) // ← 这步晚了，前面的消息全不进 confirm 流程
正确顺序：
- 创建
Channel后立刻调ch.Confirm(false) -
false表示不启用 multiple ack 的语义（更安全，避免 deliveryTag 范围误判） - 确认回调必须绑定在
Confirm调用之后、任何basicPublish之前
批量 Confirm 不是靠 setConfirmBatchSize，Go 客户端压根没这个 API
RabbitMQ 官方 Java 客户端有 channel.setConfirmBatchSize()，但 Go 的 streadway/amqp 并未实现该方法。所谓“批量”，实际是靠手动攒批 + waitForConfirms 或异步回调聚合实现的。
两种主流做法：
立即学习“go语言免费学习笔记（深入）”；
-
同步批量：循环
basicPublishN 次 → 调一次ch.waitForConfirms()，阻塞等待整批 ACK/NACK。适合吞吐可控、延迟容忍度高的场景（如离线导入） -
异步批量：用
ch.NotifyPublish()接收amqp.Confirmation流，自己维护一个sync.Map或ConcurrentSkipListMap记录每条消息的序列号（deliveryTag），在回调中按 tag 聚合统计成功/失败数量，达到阈值后触发重试或告警
注意：deliveryTag 是 per-channel 单调递增的 64 位整数，不是 UUID，不能跨 channel 复用或持久化存储做去重。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
高并发下 NotifyPublish 回调里千万别做阻塞操作
ch.NotifyPublish() 返回的是无缓冲 channel，如果回调函数里执行 HTTP 请求、DB 写入、time.Sleep 或任何可能卡住的操作，会导致整个 channel publish 链路阻塞——新消息发不出，老确认又积压，最终生产者 hang 死。
安全做法只做三件事：
- 记录日志（建议异步 logger，如
zerolog的level.Debug().Str("tag", ...).Send()） - 更新内存计数器（
atomic.AddInt64(&successCount, 1)） - 发信号给 worker goroutine（如
ackChan ，由独立 goroutine 处理重试逻辑）
重试必须另起 goroutine，且要加限流（如 semaphore.Acquire()），否则瞬时大量 nack 可能打垮下游服务。
大批量发送时，waitForConfirmsOrDie 比 waitForConfirms 更适合防雪崩
当一批发 1000 条消息，用 waitForConfirms(5 * time.Second)，超时后你只知道“这一批失败了”，但不知道哪几条失败、是否已部分落盘。而 waitForConfirmsOrDie 在超时或收到 nack 时直接 panic，配合 defer/recover + 重试队列，反而更容易做精准恢复。
关键差异：
-
waitForConfirms：返回bool，需自行判断失败后如何处理（容易忽略 nack 场景） -
waitForConfirmsOrDie：失败时直接 error，可统一捕获并把未确认消息塞进本地重试 buffer（比如ringbuffer或内存 map） - 注意它只对当前 channel 有效，若 channel 异常关闭，需重建 channel + 重放 buffer 中消息
真正难的不是攒批或发消息，而是当 broker 突然抖动、网络分区、磁盘满时，如何让这批消息不丢、不重复、不卡死——这得靠带状态的重试 buffer + deliveryTag 映射 + channel 生命周期管理，而不是依赖某个 magic batch size 参数。
