go语言中amqp.publishing的expiration字段无法可靠实现定时销毁，因rabbitmq默认忽略该字段；必须通过headers显式设置"expiration"字符串键值对，或优先使用队列级x-message-ttl参数。
Go 语言中不能直接通过 amqp.Publishing 的 Expiration 字段实现可靠定时销毁，因为 RabbitMQ 会忽略该字段——除非你用的是 AMQP 0.9.1 协议的特定实现且服务端未禁用，但实际生产环境几乎总是失效。
为什么 Expiration 字段在 Go 客户端里基本没用
RabbitMQ 官方文档明确说明：expiration 是 AMQP 0.9.1 协议中的可选字段，仅当消息尚未入队、且 broker 在投递路径中主动检查时才可能生效；而 Go 的 streadway/amqp 库在 amqp.Publishing 结构体中保留了该字段，但 RabbitMQ 默认不基于它做 TTL 判断。实测中，即使设置了 Expiration: "60000"，消息也不会在 60 秒后消失，也不会进死信队列。
- 现象：消息一直卡在队列头部，
Ready数不减，Unacked也不变，超时后仍可被消费 - 根本原因：RabbitMQ 的 TTL 机制只认两种来源——队列级
x-message-ttl或消息属性里的expiration（注意：不是amqp.Publishing.Expiration字段，而是 AMQP 内部 header 中的expiration键） - Go 客户端默认不把
Expiration字段写入 headers，所以 broker 根本看不到
正确做法：用 amqp.Table 手动注入 expiration header
必须绕过 amqp.Publishing.Expiration，改用 Headers 显式传入字符串类型的 expiration 键值对，单位毫秒，且值必须是字符串（不是 int）。
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 错误写法：
Expiration: "60000"（字段被忽略） - 正确写法：
Headers: amqp.Table{"expiration": "60000"} - 发送时需确保使用
channel.Publish()而非高层封装（如某些封装库自动抹掉 headers） - 示例片段：
err := ch.Publish(
"exchange.name",
"routing.key",
false,
false,
amqp.Publishing{
ContentType: "text/plain",
Body: []byte("hello"),
Headers: amqp.Table{"expiration": "30000"}, // ⚠️ 字符串！单位毫秒
},
)
更稳妥的选择：直接设置队列级 x-message-ttl
如果所有消息共享同一过期策略（比如统一 30 秒订单待支付），优先声明队列时设 x-message-ttl。它比单消息 TTL 更稳定、资源开销更低，且不受客户端 header 注入是否成功的干扰。
- 声明队列时添加参数：
args := amqp.Table{"x-message-ttl": 30000} - 调用
ch.QueueDeclare时传入args - 优势：无需每条消息都塞 header，避免序列化/反序列化误差；TTL 计算由 broker 统一管理
- 注意：若同时设了队列 TTL 和消息 header
expiration，以更小值为准
死信队列才是过期消息的归宿，不是“销毁”
所谓“定时销毁”，实际是 RabbitMQ 把过期消息路由到死信交换机（DLX），再转发至死信队列。如果你没配 DLX，消息就真的丢了（从原队列移除，无记录）；如果配了，它只是换了个地方待着，仍需消费者主动拉取处理。
- 必须提前声明死信交换机 + 死信队列 + 绑定关系
- 原队列声明时加两个参数：
"x-dead-letter-exchange"和"x-dead-letter-routing-key" - 过期消息不会立刻消失，而是在下次投递尝试前被检测并路由——这意味着高积压时可能延迟数秒才进 DLQ
真正要实现“定时触发”（比如 5 分钟后发通知），别依赖消息过期，改用延迟插件或外部调度器；RabbitMQ 的 TTL 本质是“过期即丢弃或移交”，不是“精确延时执行”。
