延迟消息丢失主因是交换器类型不匹配或x-delay格式错误：必须使用x-delayed-message类型交换器并正确配置x-delayed-type参数，且x-delay须为整型毫秒值。
延迟消息发出去就没了？检查 x-delayed-type 声明是否匹配
插件启用后，如果发了延迟消息但消费者完全收不到，大概率是交换器（Exchange）类型没对上。RabbitMQ 延迟队列插件要求必须用 x-delayed-message 类型的自定义交换器，不能直接往 direct 或 topic 上发带 x-delay 的消息。
实操建议：
立即学习“Python免费学习笔记（深入）”；
Swiper制作网易智造大气幻灯片
下载
这是使用 Swiper 插件制作的「网易智造」首页宽幅大气幻灯片效果，幻灯片共 6 幅，响应式设计，切换方式位淡入淡出，鼠标移入幻灯片区域显示左右箭头，移出隐藏箭头，同时设置了自动播放、延迟加载图片。
- 声明交换器时显式指定
arguments={'x-delayed-type': 'direct'}（或其他基础类型），且type参数必须是x-delayed-message - 不要复用已有
direct交换器——即使加了x-delayheader，它也不会被延迟插件识别 - 确认插件已启用：
rabbitmq-plugins list | grep delayed输出中应含[E*] rabbitmq_delayed_message_exchange（E*表示启用）
x-delay 是整数毫秒，不是字符串也不是秒
常见错误是把 x-delay 当成字符串传，比如 '5000'，或误以为单位是秒传 5。RabbitMQ 延迟插件只接受整型毫秒值，非整数或字符串会静默丢弃消息。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- Python 发送时用
pika.BasicProperties(headers={'x-delay': 30000})，确保30000是int类型 - 用
json.dumps()序列化消息体前别顺手把headers也塞进去——headers是单独传给properties的参数，不是消息体一部分 - 延迟超过 24 小时（86_400_000 ms）可能受 broker 配置限制，部分旧版本插件有毫秒级溢出风险
队列不用特殊声明，但得绑定到延迟交换器
延迟队列本身不需要加任何特殊参数，和普通队列一样声明即可。关键在绑定关系：队列必须通过标准 routing key 绑定到你创建的 x-delayed-message 类型交换器上，否则消息进不来。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 队列声明保持简洁：
channel.queue_declare(queue='delayed.task')，不加arguments - 绑定时用
channel.queue_bind(queue='delayed.task', exchange='delayed_exchange', routing_key='task') - 避免用通配符 routing key 绑定到延迟交换器——插件对 topic 匹配逻辑未优化，可能造成路由失败或延迟不准
消费者收不到延迟消息？先看消息是否真的进了队列
最常被忽略的是：消息压根没进队列，而是卡在交换器里被丢弃了。RabbitMQ 不会报错，只会静默 drop 掉无法路由的消息（尤其是绑定关系缺失或 routing key 不匹配时）。
排查步骤：
- 进管理界面（
http://localhost:15672），查交换器页签下delayed_exchange的 “Publish message” 功能，手动发一条带x-delay的测试消息，看 “Messages in queue” 是否增加 - 检查队列绑定列表，确认 routing key 和发布时用的一致（大小写、点号、空格都算不同）
- 插件不支持死信转发到另一个延迟交换器——如果想实现“重试三次后延迟 1 小时再投”，得在消费者里手动重新发，而不是靠
x-dead-letter-exchange
延迟插件本质是消息暂存+定时重投，没有真正的“时间调度器”。所有延迟精度依赖 RabbitMQ 自身的定时器粒度，高并发下可能有几十毫秒偏差，别拿它做金融级定时任务。
