rabbitmq无原生延迟消息支持，需用ttl+死信交换机实现：发送时设字符串毫秒级expiration，队列声明时配置x-dead-letter-exchange和x-dead-letter-routing-key，消费者监听死信队列而非原始队列。
延迟消息在RabbitMQ里没有原生支持，得靠TTL + 死信交换机组合实现
RabbitMQ 本身不提供 Delayed Message Plugin 以外的延迟投递能力（即使启用了插件，也需额外部署且有版本兼容风险）。生产环境更稳妥的做法是用 message TTL 配合 dead-letter-exchange（DLX）机制模拟延迟：发送时设置消息过期时间，到期后自动路由到死信队列，消费者只从死信队列取任务。
关键点在于：延迟逻辑不在生产者侧计算，而由 RabbitMQ 自身 TTL 控制；必须确保目标队列声明时绑定 DLX 和 DLK（dead-letter-routing-key），否则过期消息会直接被丢弃。
-
queueDeclare必须显式传入x-dead-letter-exchange和x-dead-letter-routing-key参数 - 不要给 exchange 设置 TTL —— 只能对 message 或 queue 设 TTL，且优先级：message TTL > queue TTL
- 若用
amqp.Publishing发送，Expiration字段值是字符串格式的毫秒数（如"5000"），不是 int
Go 客户端发延迟消息时，Expiration 字段容易写错类型或单位
很多开发者误把 Expiration 当成整型或秒级数值，导致消息永不超时或立即过期。它必须是字符串，单位是毫秒，且只对当前这条消息生效。
err = ch.Publish(
"", // exchange
"delay_queue", // routing key
false,
false,
amqp.Publishing{
ContentType: "application/json",
Body: []byte(`{"order_id":"123"}`),
Expiration: "30000", // ✅ 字符串，30秒
},
)
- 如果填
30000（int）或"30"（秒），RabbitMQ 会忽略该字段或触发错误 - 若同时设置了 queue 级 TTL（
x-message-ttl），单条消息的Expiration仍会覆盖它 - 注意 AMQP 协议限制：Expiration 是“尽力而为”，不保证精确到毫秒，通常误差在 100–500ms
死信队列消费者不能直接监听原始队列，要单独声明并绑定 DLX 目标
延迟消息真正可消费的地方，是那个被配置为死信目的地的队列，而不是你发消息进去的那个“延迟队列”。很多人卡在这一步：以为往 delay_queue 发完就能从它里面消费，结果一直收不到。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
正确做法是：另建一个普通队列（比如 real_task_queue），让它绑定到你预先定义好的死信 exchange（比如 dlx_exchange），routing key 对应当初设的 x-dead-letter-routing-key。
- 原始队列（
delay_queue）只负责接收 + 过期 + 转发，不建议从中消费 - 死信 exchange 类型必须是
direct或topic，不能是fanout（否则无法按 routing key 分发） - 消费者连接的是
real_task_queue，不是delay_queue
高并发下大量短延迟消息会导致 RabbitMQ 内存压力激增
每条带 TTL 的消息都会被 RabbitMQ 放进内存中的定时器队列管理，如果批量推送 10 万条 1 秒后到期的消息，RabbitMQ 可能瞬间吃光内存、触发流控甚至崩溃。
缓解方式不是调大内存，而是从设计上规避：
- 用分片延迟：把 1 秒延迟拆成 10 个 100ms 队列轮询，降低单队列定时器负载
- 改用外部调度器（如 Redis ZSET + 定时轮询）做粗粒度延迟，RabbitMQ 只做最终投递
- 避免
Expiration设置过小（
真正复杂的延迟场景——比如订单超时关单、预约提醒、重试退避——建议用专用延迟中间件（如 Apache RocketMQ 的定时消息、或 Redis + worker 组合），RabbitMQ 做好它擅长的事：可靠投递和削峰即可。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
