RabbitMQ 的 channel.Tx() 因吞吐极低（200–300 msg/s）且仅保证发到 Broker、不保障消费成功或一致性，生产环境绝对禁用；可靠事务消息需依赖本地事务+可靠投递+补偿校验。
Go 语言本身没有“事务消息”原语，RabbitMQ 的事务（channel.Tx()）在生产环境几乎不用——它会把吞吐压到个位数，且无法解决分布式一致性问题。真正可靠的事务消息，靠的是「本地事务 + 可靠投递 + 补偿校验」三件套，不是靠 AMQP 协议层的 Tx/Commit。
为什么 RabbitMQ 的 channel.Tx() 绝对不能用
AMQP 的事务机制会让每条 publish 都同步等待 Broker 写盘并返回 ACK，实测吞吐跌到 200–300 msg/s；更致命的是，它只保证“发到 Broker”，不保证消费者能收到、不保证业务处理成功、也不防网络分区丢消息。线上服务一旦启用，等于主动给自己加锁。
-
channel.Tx()和channel.Confirm()互斥，开了事务就无法用更高效的 confirm 模式 - 事务失败时只能 rollback 整个 channel，无法精细控制某几条消息
- Go 客户端
streadway/amqp对事务的错误处理极不友好：panic 不明确、恢复逻辑难写
autoAck: false 是事务消息落地的第一道铁闸
几乎所有重复消费、消息丢失的线上事故，都始于忘记关掉 autoAck: true。它让 RabbitMQ 在把消息推给 Go 进程内存的瞬间就删掉消息，哪怕 msg.Body 还没开始解析，进程已 panic，消息也永不重试。
- 必须设为
autoAck: false，并在业务逻辑执行成功后显式调用msg.Ack(false) - 失败时用
msg.Nack(false, true)让消息重回队列头部（注意：要配死信交换机，否则会无限循环） - 绝不能在
for range msgs外写defer msg.Ack()——那会把整批消息提前确认掉 - 用
ctx, cancel := context.WithTimeout(ctx, 30*time.Second)包裹处理逻辑，超时直接Nack
消息体为空 {}？90% 是结构体字段未导出
Go 的 json.Marshal 对小写首字母字段完全静默忽略，不会报错也不会警告，你看到的空 JSON 就是它干的。这不是 RabbitMQ 的问题，是 Go 编码规则踩坑。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 结构体字段名必须大写开头：
OrderID string，不能是orderID - JSON tag 必须带双引号：
json:"order_id"，不是json:order_id或json:"order_id"（少引号） - 如果用了嵌套结构体，每一层都要检查导出性；
time.Time要配json:"created_at" time_format:"2006-01-02"
持久化配置三处漏一，等于没开
amqp.Publishing{DeliveryMode: amqp.Persistent} 单独设了也没用。RabbitMQ 的持久化是端到端链路：生产者发、Exchange 存、Queue 存、Consumer 确认，缺一不可。
- 声明 Exchange 时必须传
durable: true，否则重启后绑定丢失，消息静默丢弃 - 声明 Queue 时也要
durable: true，且autoDelete: false - 发送时用默认交换机（
""）要注意：它只支持direct路由，routingKey必须严格等于队列名，极易配错 - 验证方法：进 RabbitMQ 管理界面，看 Queue 的
Durability列是否为Yes，再点开 Message 查Delivery mode是否为2
事务消息的本质不是“让 MQ 支持两阶段提交”，而是让业务代码承担起幂等、重试、状态快照和最终一致的责任。RabbitMQ 只提供可靠管道，剩下的事，得在 HandleMessage 里一行行写清楚。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
