rabbitmq延迟队列必须启用rabbitmq_delayed_message_exchange插件并正确声明exchange类型，或采用ttl+dlx方案严格配置三者关系，且消费端必须实现幂等；go客户端需校验exchange存在性与类型一致性。
插件法必须启用 rabbitmq_delayed_message_exchange 且声明正确 Exchange 类型
不装插件就别谈“RabbitMQ 延迟队列”——原生 RabbitMQ 真的不支持。当前主流镜像 rabbitmq:4-management 默认满足插件运行条件（Erlang ≥ 18.0，实际为 27.3.2），但插件默认未启用：rabbitmq-plugins enable rabbitmq_delayed_message_exchange 必须手动执行。
Go 客户端声明 Exchange 时，amqp.ExchangeDeclare 的参数表里必须包含 amqp.Table{"x-delayed-type": "direct"}（或 "topic"），否则会直接报错 channel error: "invalid argument"。注意：autoDeleted 参数必须设为 false，该 Exchange 不支持 auto-delete。
发消息时不能用 Expiration 字段，那是 TTL 方案用的；必须走 Headers：Headers: amqp.Table{"x-delay": 5000}，单位是毫秒，整数即可，不用字符串。
TTL+DLX 方案三个配置点必须严格对齐，漏一个就丢消息
这个方案不依赖插件，但链路更长、容错更低：要同时配好延迟队列、死信交换机、死信队列三者之间的关系，且每个环节都有易错细节。
- 延迟队列声明时必须带两个参数：
x-dead-letter-exchange（指向死信交换机名）和x-dead-letter-routing-key（指定路由键），缺一不可 - 消息的 TTL 必须设为字符串，例如
"60000"，设成整数60000会被 RabbitMQ 静默忽略 - 死信队列自身不能设
x-message-ttl，否则它收到的消息可能立刻再次过期，引发无限循环或二次丢失
若每条消息延迟时间不同，只能对每条消息单独设 Expiration；若统一延迟（如所有订单都 10 分钟关单），就对队列设 x-message-ttl 更省事。
消费端不做幂等，延迟队列就是定时炸弹
RabbitMQ 不保证“恰好一次”，无论插件法还是 TTL+DLX，网络抖动、Broker 重启、消费者 crash 后重连，都可能导致同一条延迟消息被重复投递。
常见错误是写个 if order.Status == "created" { cancelOrder() } 就完事——这根本扛不住重复。正确做法是：
- 用订单 ID + 状态机判断是否已取消，比如先查 DB 记录状态，再更新为 “canceled” 并带
WHERE status = 'created' - 避免在消费逻辑里做非幂等副作用：不要直接扣库存、发短信；应先落库标记
task_status = 'triggered'，再异步触发后续动作 - 死信队列本身也要监控：
dlx.queue的长度和unacknowledged数量突增，往往意味着 DLX 路由失败或消费者卡住
Go 客户端发延迟消息前，必须确认 Exchange 已存在且类型匹配
很多人在 Go 里调用 amqp.ExchangeDeclare 后没检查返回错误，或者误以为“声明一次就行”，结果在生产环境发现消息发不出去，日志里只有模糊的 NO_ROUTE。
根本原因是：Exchange 不存在，或存在但类型不是 x-delayed-message（插件法）或 direct（TTL 法）。建议在启动时显式检查：
_, err := ch.ExchangeDeclarePassive(
"delayed.exchange",
"x-delayed-message",
true,
false,
false,
false,
nil,
)
如果 err != nil，说明 Exchange 没创建好或类型不对，此时应 panic 或告警，而不是静默继续。
真正麻烦的从来不是写几行 ch.Publish，而是确保整个 AMQP 拓扑在部署后始终处于预期状态——尤其是延迟相关 Exchange 和 Queue 的参数一致性，容易被 CI/CD 脚本漏掉或覆盖。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
