插件法更推荐，ttl死信法仅用于无法安装插件的旧环境；rabbitmq原生不支持延迟队列，必须通过rabbitmq_delayed_message_exchange插件（声明x-delayed-message交换机并用x-delay头发送）或ttl+dlx组合（配置队列ttl及死信交换机参数）实现，且消费端必须做幂等处理。
直接说结论：插件法更推荐，TTL死信法只在无法装插件的旧环境里兜底。 RabbitMQ 原生不支持延时队列，Go 里写代码也绕不开这个事实——所有“延迟发送”都得靠两种底层机制之一，不是选语法糖，而是选基础设施支撑方式。
用 rabbitmq_delayed_message_exchange 插件最省事
装好插件后，Go 客户端只需声明一个特殊类型的 Exchange，并在发消息时塞 x-delay 头，不用改消费逻辑，延迟精度也够用（实测漂移 50–200ms）。
- 插件启用命令：
rabbitmq-plugins enable rabbitmq_delayed_message_exchange，要求 RabbitMQ ≥ 3.5.7、Erlang ≥ 18.0；当前主流镜像rabbitmq:4-management默认满足（Erlang 27.3.2） - Exchange 声明必须带参数：
amqp.Table{"x-delayed-type": "direct"}（或"topic"），否则ExchangeDeclare会失败 - 发消息时不能用
Expiration字段，必须走Headers：Headers: amqp.Table{"x-delay": 5000}，单位是毫秒 - 该 Exchange 不支持
auto-delete，声明时autoDeleted参数必须为false
TTL + DLX 方案配置链长、易漏项
不依赖插件，但要手动搭两套 Exchange + Queue，且三个关键配置点必须对齐，漏一个消息就卡住或丢弃。
- 延迟队列（如
delay.queue）必须设置x-dead-letter-exchange和x-dead-letter-routing-key，指向死信交换机和路由键 - 消息 TTL 必须设为字符串，比如
"60000"，不是整数60000；设成整数会静默忽略 - 死信队列本身不能设
x-message-ttl，否则它收进来的消息又过期，可能触发无限循环或二次丢失 - 若每条消息延迟时间不同，只能对每条消息单独设
Expiration；若统一延迟，就对队列设x-message-ttl
Go 消费端必须做幂等处理
无论哪种方案，RabbitMQ 都不保证延迟消息只投递一次。网络抖动、Broker 重启、消费者 crash 后重连，都可能导致重复消息抵达。
- 别依赖 “延迟时间准不准”，先确保业务逻辑能扛住重复：比如用订单 ID + 状态机判断是否已取消，而不是无条件执行取消动作
- 避免在消费逻辑里做非幂等副作用，例如直接扣库存、发短信；应先落库标记“已触发”，再异步执行
- 死信队列里的消息，也可能因 DLX 路由失败而堆积，需监控
dlx.queue的长度和未确认数
真正麻烦的从来不是写几行 amqp.Publishing，而是 TTL 值填错类型、DLX 路由键拼错、插件没声明 x-delayed-type —— 这些错误不会报 panic，只会让消息无声消失或永远卡在队列里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
