RabbitMQ在Go中无开箱即用的可靠方案，必须手动控制Ack、全链路持久化、超时防护与幂等设计；autoAck设为false是可靠消费前提，需显式Ack/Nack，配合context超时、durable声明、confirm模式、导出结构体字段及合理连接复用。
RabbitMQ 在 Go 中根本不存在“开个开关就可靠”的方案，所有所谓“可靠”都建立在手动控制 Ack、持久化链路完整、超时防护和幂等兜底之上。
autoAck: false 是可靠消费的第一道铁闸
设成 true 就等于告诉 RabbitMQ：“消息一进我内存，立刻删掉”。哪怕你的业务逻辑第一行就 panic，消息也永远不重试——这是订单重复扣款、积分漏发最常见源头。
- 必须显式传
autoAck: false给ch.Consume() - 成功处理后调用
msg.Ack(false)，失败时用msg.Nack(false, true)让消息重回队列头部 - 千万别在
for range msgs外写defer msg.Ack()——那会把整批消息提前确认掉 - 加一层保护：
ctx, cancel := context.WithTimeout(ctx, 30*time.Second)包裹业务逻辑，超时直接Nack
DeliveryMode: amqp.Persistent 不生效？检查这三处
amqp.Publishing{DeliveryMode: amqp.Persistent} 单独设了没用。RabbitMQ 的持久化是端到端链路：生产者发、Exchange 存、Queue 存、Consumer 确认，缺一不可。
- 声明 Exchange 时漏掉
durable: true？RabbitMQ 重启后绑定消失，消息静默丢弃 - 声明 Queue 时没设
durable: true？队列非持久，Broker 重启即失 - 用了空字符串
""当 exchange 名？默认交换机只支持 direct 路由，且routing_key必须严格等于队列名——极易误配 - 验证方法：RabbitMQ 管理界面看 Queue 的
Durability列是否为Yes，再看 Message 的Delivery mode是否为2
channel.Confirm() 是唯一可落地的生产端确认方式
channel.Tx() 在生产环境绝对禁用：吞吐压到 200–300 msg/s，且只保证“发到 Broker”，不防网络分区、不保消费成功。真正能用的只有 confirm 模式。
立即学习“go语言免费学习笔记（深入）”；
- 启用：
ch.Confirm(false)，之后所有ch.Publish()都进入异步确认流 - 监听确认：
confirms := ch.NotifyPublish()，从该 channel 读取amqp.Confirmation - 失败必须重试：收到
!confirm.Ack后，按指数退避重发（注意避免死循环） - 别漏本地记录：发消息前先写入本地消息表或数据库，状态为 “sending”，确认成功后再更新为 “sent”
消息体为空 {}？90% 是结构体字段未导出
Go 的 json.Marshal 对小写首字母字段完全静默忽略，不报错也不警告。你看到的空 JSON 就是它干的——这不是 RabbitMQ 的问题。
- 结构体字段名必须大写开头：
OrderID string，不能是orderID -
jsontag 必须带双引号：json:"order_id"，不是json:order_id或json:"order_id"（少引号） - 嵌套结构体每一层都要检查导出性；
time.Time字段要配json:"created_at" time_format:"2006-01-02" - 建议加单元测试：
jsonBytes, _ := json.Marshal(yourStruct); fmt.Printf("%s", jsonBytes)直接看输出
最容易被忽略的是连接与 channel 生命周期管理：一个服务实例只建 1 个 *amqp.Connection，复用它创建多个 *amqp.Channel；频繁 Dial() 会快速耗尽本地端口；关闭顺序必须是 ch.Close() → conn.Close()，反着来会导致 channel 泄露，后续 Consume() 直接 panic。
