高频发券需在Go客户端层做三件事：连接复用防超时、手动ACK防重投、幂等控制防重复；须全局单例连接、禁用autoAck、用message_id+Redis实现强幂等，并启用delayed_exchange插件处理延迟消息。
高频发券场景下，接口响应超时和重复发券不是 RabbitMQ 的 bug，而是没对齐它的语义模型：它默认保障“至少一次投递”，不承诺“恰好一次”。想让发券又快又准，必须在 Go 客户端层做三件事——连接复用防超时、手动 ACK 防重投、幂等控制防重复。
amqp.Dial 不能写在 HTTP handler 里
每次 HTTP 请求都调一次 amqp.Dial()，50 QPS 就可能打满本地 ephemeral port，报 connect: cannot assign requested address。这不是 RabbitMQ 拒绝你，是操作系统端口耗尽了。
- 全局只初始化一个
*amqp.Connection，用sync.Once或 DI 初始化，配Heartbeat: 10 * time.Second防云环境静默断连 - 连接字符串加超时参数：
"amqp://guest:guest@localhost:5672/?connect_timeout=5"，避免 DNS 卡死整个 goroutine - 发消息前用
conn.Channel()拿新*amqp.Channel，用完立刻ch.Close()；*amqp.Channel不是线程安全的，别跨 goroutine 复用
消费者必须 autoack=false + 显式 ack
如果用 autoAck=true，消息一到就确认，业务失败也收不到重试——但更危险的是：消费者处理慢（比如调第三方发券接口卡住）、网络抖动导致 ACK 丢包，RabbitMQ 会认为消息没消费成功，过几秒再推一遍，直接触发重复发券。
- 声明 consumer 时传
autoAck: false - 业务逻辑包裹在
defer func() { if r := recover(); r != nil { ch.Nack(delivery.DeliveryTag, false, true) } }()里防 panic - 仅当 DB 写入成功、Redis 幂等标记落库后，才调
delivery.Ack(false)；失败则delivery.Nack(false, true)让消息重回队列头部（慎用）或进死信队列
message_id + Redis 实现强幂等
光靠 ACK 不够。生产者重试、Broker 重启、网络分区都可能导致同一条消息被投递多次。必须在消费端拦截——用消息唯一标识做原子判重。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 发券消息体里带业务字段
order_id和全局唯一message_id（推荐用 UUIDv4 或 Snowflake） - 消费时先
SETNX redis_key message_id EX 3600，key 格式建议coupon:dedup:{order_id}:{message_id}，TTL 设为业务最大处理周期（比如 1 小时） - SETNX 返回 0 表示已存在，直接
delivery.Ack(false)退出；返回 1 则继续执行发券逻辑 - 别用纯内存 map 做去重——单机部署还行，多实例时完全失效
延迟消息必须用插件，别碰 TTL+DLX
优惠券常需“支付成功后 10 分钟发”，有人想用队列级 x-message-ttl + DLX 模拟，结果发现延迟不准、消息卡死、配置漏项就丢消息。这不是调参问题，是模型不匹配。
- 启用
rabbitmq_delayed_message_exchange插件（RabbitMQ ≥ 3.5.7，默认镜像已支持） - 声明 Exchange 时指定类型
x-delayed-message和amqp.Table{"x-delayed-type": "direct"} - 发消息时只设
Headers: amqp.Table{"x-delay": 600000}（单位毫秒），别碰Expiration字段 - 延迟消息一样会重复投递，幂等逻辑不能省
真正难的不是写代码，是把每条消息的生命周期拆解清楚：从 amqp.Dial 建连开始，到 channel.Publish 发出，再到消费者拿到 delivery、查 Redis、写 DB、发 ACK——中间任意一环没对齐语义，超时或重复就藏在里面。尤其是多实例部署时，连接单例、幂等 key 设计、延迟插件启用状态，三个点漏一个，线上就报警。
