RabbitMQ的autoAck=true是线上最大隐患，因其在消息送达消费者内存瞬间即删除消息，不等待业务执行完成，导致panic、OOM或滚动更新时消息永久丢失。
生产环境必须禁用 autoAck=true，否则消息会在业务逻辑执行前就被确认，一旦 panic、OOM 或滚动更新，消息永久丢失。
为什么 RabbitMQ 的 autoAck=true 是线上最大隐患
RabbitMQ 一发消息就认为“已送达”，根本不等你业务跑完。微服务里一次 panic、一次内存溢出、一次 K8s 滚动更新，都可能触发消息黑洞。这不是功能缺陷，是设计契约：它只管投递，不管执行。
-
autoAck=true下，ch.Consume()返回的msgschannel 一吐出消息，RabbitMQ 立即从队列删掉——哪怕你的 handler 还没开始跑 - 正确做法是设
autoAck=false，在业务逻辑彻底成功后，显式调用msg.Ack(false) - 若处理失败且不可重试（如数据库唯一键冲突），用
msg.Nack(false, false)拒绝并丢弃；若可重试，用msg.Nack(false, true)让消息重回队尾 -
delivery对象绑定到特定amqp.Channel，跨 goroutine 传递时必须连同ch一起传，否则Ack()会 panic 报"invalid channel"
ch.Qos(1, 0, false) 不只是性能优化，是避免消费者“饿死”的关键
预取数（prefetch count）设太高，单个消费者会一口气拉走几十条消息，卡在本地 goroutine 里处理；其他实例空转，队列积压却无法分摊——这在高并发场景下就是隐性雪崩。
-
ch.Qos(1, 0, false)表示最多允许 1 条未确认消息在途，强制 RabbitMQ 等你Ack()后再发下一条 - 别用
ch.Qos(10, 0, false)图省事，尤其当消息处理耗时波动大时，容易导致某实例长期占用大量消息，其余实例“吃不饱” - 该设置需在
ch.Consume()之前调用，且对每个Channel独立生效
连接和 Channel 复用不是最佳实践，是生存底线
每次 HTTP 请求都 amqp.Dial()？端口会快速耗尽，TLS 握手风暴会让 K8s NetworkPolicy 主动断连，连接建立失败率飙升。
- 用单例或依赖注入封装
*amqp.Connection，例如internal/mq/rabbitmq.go中的NewRabbitMQConn() - 连接配置必须含
amqp.Config{Heartbeat: 10 * time.Second}，避开云环境默认 30 秒心跳与空闲超时冲突 -
Channel不是线程安全的：每个 goroutine 处理消息前调用ch, _ := conn.Channel()，用完立刻ch.Close()；切勿全局复用一个Channel - 声明队列时
durable: true是底线，但仅此不够——发送消息还得加DeliveryMode: amqp.Persistent才能持久化消息体
幂等不能只靠 message_id，得靠业务语义唯一键 + 状态检查
网络重试、消费者 crash 后重连、镜像同步延迟，都会造成同一条消息被投递两次。而 message_id 是客户端生成的 UUID，不含业务含义，也无法覆盖字段动态变化（如时间戳、随机数）的场景。
- 消息体必须带业务语义唯一键，比如
{"order_id": "ORD-20260119-789", "event_type": "payment_succeeded"} - 消费者先查 DB/Redis 是否已存在该
order_id + event_type的成功记录，再执行业务逻辑 - 推荐用 Redis 的
SET key value EX 3600 NX做轻量幂等锁；失败则直接Nack，避免阻塞主流程 - 所有消息解析必须用结构体指针 + 正确
json:tag，导出字段名首字母大写，否则json.Marshal()静默忽略字段，body 变成空对象
最常被跳过的其实是连接断开监听：conn.NotifyClose() 和 defer ch.Close() 必须配对使用，否则 channel 泄露后，新 consumer 创建会失败，错误日志里只显示 “channel error”，没有根源线索。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
