必须用单例或依赖注入管理amqp.Connection，配置心跳避免断连；Channel需每goroutine独立创建；队列设durable:true/autoDelete:false/exclusive:false；消息Publish时设DeliveryMode:Persistent；消费者禁用autoAck，手动ACK/NACK并设QoS；消息带版本头和vhost隔离。
能用，但必须按微服务场景重构连接和错误处理逻辑，不能照搬单体示例代码。
如何在Kratos等Go微服务框架中安全复用RabbitMQ连接
RabbitMQ的amqp.Connection是重量级资源，不能每次发消息都amqp.Dial()再conn.Close()——这会导致连接风暴、端口耗尽，且Kratos的gRPC/HTTP服务启动后长期运行，连接理应复用。
- 必须用单例或依赖注入方式管理
*amqp.Connection，例如在Kratos的internal/mq/rabbitmq.go中封装NewRabbitMQConn()并缓存 - 连接需配置
amqp.Config{Heartbeat: 10 * time.Second}，避免被RabbitMQ主动断连（默认心跳30秒，而很多K8s网络策略会掐掉空闲连接） - 不要把
ch, err := conn.Channel()也做成全局单例：Channel不是线程安全的，每个goroutine应自己ch, _ := conn.Channel()再用完ch.Close()
ch.QueueDeclare的持久化参数必须与业务语义对齐
微服务部署常跨环境（dev/staging/prod），队列是否自动删除、是否持久化，直接影响消息可靠性。例如订单服务发送“支付成功”事件，若队列非持久化，RabbitMQ重启后消息就丢了。
-
durable: true→ 队列本身存盘，RabbitMQ重启不消失（必须设为true用于核心业务） -
autoDelete: false→ 避免最后一个消费者断连后队列被删（微服务滚动更新时常见） -
exclusive: false→ 排他队列只允许一个连接使用，无法支持多实例消费 - 注意：
durable只保证队列元数据不丢，消息是否持久还需在ch.Publish()时设amqp.Publishing{DeliveryMode: amqp.Persistent}
消费者端必须手动ACK，否则消息会堆积或重复消费
Kratos服务作为消费者时，默认autoAck: true看似省事，但一旦服务崩溃或OOM，未处理完的消息直接被RabbitMQ标记为已投递，永久丢失。
立即学习“go语言免费学习笔记（深入）”；
- 务必设
autoAck: false，并在业务逻辑执行成功后显式调用delivery.Ack(false) - 用
ch.Qos(1, 0, false)限制预取数（prefetch count），防止一个消费者积压大量消息导致其他实例饿死 - 遇到panic或不可恢复错误，用
delivery.Nack(false, true)让消息重回队尾，避免卡死 - 注意：ACK/NACK必须在同一个Channel上调用，跨goroutine传递
amqp.Delivery时别漏传ch
微服务间消息格式建议用JSON Schema + 版本字段
不同服务由不同团队维护，消息结构易不一致。直接传裸JSON或map[string]interface{}会导致消费者解析失败却无明确提示。
- 在消息body开头加
{"version":"v1","event":"order_paid"}，消费者先校验version再反序列化 - 用
amqp.Publishing{Headers: map[string]interface{}{"content-type": "application/json; version=v1"}}带版本头，比塞进body更正交 - 避免用Go struct的
json:"-"忽略字段——下游可能升级了struct但没改消息格式，导致字段静默丢失
最常被跳过的点：RabbitMQ的virtual host（vhost）在微服务里不是可选项。Kratos各服务应分配独立vhost（如/svc-order、/svc-user），而非共用/，否则权限隔离和监控粒度全失效。这个配置藏在amqp.Dial("amqp://user:pass@host:5672/svc-order")的URL末尾，容易被忽略。
