RabbitMQ延迟队列需通过TTL+死信交换机（DLX）组合实现，精度秒级、延迟时间publish时固定为字符串毫秒值，且必须完整配置x-dead-letter-exchange与x-dead-letter-routing-key，否则消息丢弃。
延迟队列不是RabbitMQ原生功能，得靠TTL+死信交换机组合实现
rabbitmq本身没有x-delayed-message插件以外的内置延迟队列支持。pika作为纯python客户端，也不封装延迟逻辑——它只负责发消息、绑队列、声明交换机。真正起作用的是服务端配置：先给消息设expiration（ttl），再让过期消息被自动路由到另一个“死信交换机”（dlx），最终投递到你指定的延迟消费队列。
这意味着：不装插件的前提下，延迟精度是秒级（最低1000ms），且延迟时间必须在publish()时就写死，不能动态计算；同时，每个延迟队列需单独绑定DLX，不能复用一个“通用延迟队列”来处理多种延时任务。
声明带死信参数的队列时，arguments必须同时配全x-dead-letter-exchange和x-dead-letter-routing-key
漏掉任一参数，消息过期后会直接丢弃，不会进死信流程。常见错误是只设了DLX但没设DLK（死信routing key），导致消息卡在AMQP默认死信队列里无法路由出去。
-
x-dead-letter-exchange：必须是已存在的exchange名称，类型建议为direct或topic，不能是fanout（否则无法按key路由） -
x-dead-letter-routing-key：要跟后续绑定的延迟消费队列的binding key完全一致 -
x-message-ttl可选：如果想让整个队列的消息统一过期（比如所有消息最多等30秒），才在这里设；否则应在publish()时通过expiration单独控制每条消息
示例声明（使用Pika）：
channel.queue_declare(
queue='delayed_task_queue',
arguments={
'x-dead-letter-exchange': 'dlx_exchange',
'x-dead-letter-routing-key': 'delayed.task',
'x-message-ttl': 60000 # 整队列统一TTL，单位毫秒
}
)
basic_publish()里加expiration参数才能实现单消息级延迟
很多人误以为只要队列有x-message-ttl就能延迟，其实那只是兜底策略。真要按业务需要发5秒后执行、30秒后重试、2小时后提醒，必须在每条消息publish时显式传expiration。这个值是字符串格式的毫秒数，不是整数。
Python 3.14.3
微软官方的 Python 扩展，是 VS Code 安装量最高的扩展（209M+）。集成 IntelliSense（通过 Pylance）、调试（通过 Python Debugger）、代码检查、格式化、重构和单元测试等功能。支持 Jupyter Notebook、虚拟环境管理和多 Python 版本切换。
- 必须是字符串，比如
'5000'，传5000会报错：TypeError: a bytes-like object is required, not 'int' - 最大值受服务端配置限制，默认上限是
2^32-1毫秒（约49天），但实际建议别超7天，避免队列堆积 - 注意时区无关：RabbitMQ按服务端系统时间算，不是客户端时间
示例发布带延迟的消息：
properties = pika.BasicProperties(
delivery_mode=2, # 持久化消息
expiration='10000' # 10秒后过期
)
channel.basic_publish(
exchange='',
routing_key='delayed_task_queue',
body=json.dumps({'job_id': 123}),
properties=properties
)
消费端不需要特殊处理，但要注意DLX交换机和绑定关系必须提前建好
延迟消息最终落到你指定的“真正消费队列”，比如real_consumer_queue，这个队列本身不需要任何特殊参数，它只是普通队列。关键在于：它的上游DLX交换机（比如dlx_exchange）必须存在，且已经把delayed_task_queue的过期消息路由到它身上。
- DLX交换机要用
channel.exchange_declare()显式声明，类型不能是headers - 必须调用
channel.queue_bind()把DLX和真实消费队列绑定，routing key要和之前x-dead-letter-routing-key一致 - 如果跳过这步，消息过期后会“消失”，连warning日志都不打
容易忽略的一点：Pika的channel是短生命周期对象，每次连接后都要重新declare所有exchange/queue/bindings，不能假设上次连接留下的结构还在。
