生产环境必须禁用 autoAck=true，因其导致消息未处理完即被确认而永久丢失；应设 autoAck=false 并显式 Ack/Nack，配合 QoS、持久化、幂等设计与死信队列保障可靠性。
为什么 RabbitMQ 的 autoAck 设为 true 是生产环境最大隐患
不是功能不全，而是它会让消息在消费者崩溃瞬间永久丢失——RabbitMQ 一发出去就认为“已送达”，根本不等你业务逻辑跑完。微服务滚动更新、OOM 或 panic 都会触发这个黑洞。
- 必须设
autoAck: false，并在业务处理成功后显式调用delivery.Ack(false) - 若处理失败且不可重试（如数据库唯一键冲突），应调用
delivery.Nack(false, false)拒绝并丢弃；若可重试，用delivery.Nack(false, true)让消息重回队尾 -
delivery对象绑定到特定amqp.Channel，跨 goroutine 传递时务必连同ch一起传，否则Ack()会 panic 报"invalid channel" - 搭配
ch.Qos(1, 0, false)限制预取数，避免单个消费者积压几十条消息，导致其他实例“饿死”
连接和 Channel 管理：别让 amqp.Dial() 在每个 HTTP 请求里执行
频繁 amqp.Dial() 会导致端口耗尽、TLS 握手风暴，K8s 环境下常被 NetworkPolicy 主动断连。Kratos、Gin 等框架启动即长驻，连接必须复用。
- 用单例或依赖注入封装
*amqp.Connection，例如internal/mq/rabbitmq.go中的NewRabbitMQConn() - 连接配置必须含
amqp.Config{Heartbeat: 10 * time.Second}，避开默认 30 秒心跳与云网络空闲超时冲突 -
Channel不是线程安全的，每个 goroutine 处理消息前调用ch, _ := conn.Channel()，用完立刻ch.Close()；切勿全局复用一个Channel - 声明队列时
durable: true是底线——否则 RabbitMQ 重启，队列元数据直接消失；但光设这个不够，发送消息还得加DeliveryMode: amqp.Persistent才能持久化消息体
消息重复与幂等：别只靠 message_id 做去重
网络重试、消费者 crash 后重连、RabbitMQ 镜像同步延迟，都可能造成同一条消息被投递两次。仅校验 message_id 无法覆盖所有场景，尤其当消息体含时间戳或随机字段时。
- 消息体必须带业务语义唯一键，比如
{"order_id": "ORD-20260119-789", "event_type": "payment_succeeded"}，而非自动生成的 UUID - 消费者需先查 DB/Redis 是否已存在该
order_id + event_type的成功记录，再执行业务逻辑；成功后立即写入状态表（task_status表中status = 'success'） - 推荐用 Redis 的
SET key value EX 3600 NX做轻量幂等锁，失败则直接NACK，避免阻塞主流程 - 所有消息解析必须用结构体 +
json.Unmarshal()，失败即NACK并打结构化日志，不静默跳过
死信队列（DLQ）不是备胎，而是故障定位第一现场
没有 DLQ 的 RabbitMQ 消费者，就像没有刹车的车——失败消息反复重试，最终卡死整个队列，新消息进不来，监控也只报“消费延迟高”，根本看不出哪条消息在捣鬼。
立即学习“go语言免费学习笔记（深入）”；
- 队列声明时必须配置
args: amqp.Table{"x-dead-letter-exchange": "dlx", "x-dead-letter-routing-key": "dlq.order"} - 给消息设 TTL（如
Expiration: "30000"），或靠消费者NACK触发重试计数，累计 3 次失败自动转入 DLQ - DLQ 自身也要
durable: true，并配独立消费者——只做两件事：记录原始消息到 ES/MySQL，发告警（如企业微信机器人） - 别在 DLQ 消费者里尝试“修复重试”，它只负责归档和告警；人工排查后，从 DLQ 中提取消息重发到原队列即可
RabbitMQ 在 Go 微服务里真正难的从来不是“怎么连上”，而是连接怎么不死、消息怎么不丢、重复怎么不崩、失败怎么可查——这些点没对齐，再多的 goroutine 也救不了系统稳定性。
