routing_key必须严格匹配task_type且仅表达语义类型，不可含动态id；重试与重放需用带版本前缀的新key，避免混用旧key导致路由错乱或状态冲突。
路由键命名必须与 task_type 严格一致
消息进队列时设置的 routing_key，必须和消费者端声明绑定的 key 完全相同，大小写、下划线、连字符都不能差。RabbitMQ 不做模糊匹配，chat 和 chat_v2 是两条完全隔离的路由路径。
常见错误现象：任务始终不被消费，rabbitmqctl list_bindings 查看绑定关系时发现 key 对不上；或消费者日志里反复打印“no matching consumer”，其实是 key 拼错或多空格。
- ThinkPHP 的
think-queue默认把job类名转成小写下划线格式，比如SendEmailJob→send_email_job，但你得确认它没被中间件或配置覆盖 - Laravel 的
dispatch()不自动推导 routing_key，需显式传参：SendImageJob::dispatch()->onQueue('image')，此时队列名image就是 routing_key（前提是 exchange 类型为 direct） - 若用 topic exchange，key 可带通配符，如
task.chat.*，但务必同步更新消费者绑定逻辑，否则匹配失效
避免在 routing_key 中嵌入动态 ID 或时间戳
routing_key 应表达语义类型，不是实例标识。把 user_12345 或 order_20260827 当作 key，会导致 RabbitMQ 内部路由表膨胀、无法复用消费者、监控粒度失焦。
真正需要区分上下文的字段，应放进消息体（body），而不是 key。key 只负责“哪类任务走哪条通道”，body 才承载“这个任务具体是谁、要干什么”。
- 错误示例：
channel.publish(exchange, 'task.order.12345', payload)—— 12345 是订单 ID，不该出现在 key 里 - 正确做法：
channel.publish(exchange, 'task.order', array_merge($payload, ['order_id' => 12345])) - 例外场景：极少数需按租户隔离的 SaaS 架构，可用
tenant_a.task.order，但必须确保 tenant_id 是预定义白名单，而非任意字符串
重试队列的 routing_key 必须带版本前缀
原始任务失败后转入重试队列，若仍用原 routing_key，会和新任务混在一起，导致重试被提前消费、或新任务被误判为重试。标准做法是加前缀，如 retry.v1.chat、retry.v2.image。
这个前缀不只是为了区分，更是为了支持不同重试策略：v1 可能延迟 1s 后投递，v2 改为指数退避；消费者也需按前缀绑定不同逻辑，比如 v1 重试不记录日志，v2 则上报告警。
- ThinkPHP 的
think-queue默认不处理重试 key 变更，需重写retry方法，在push前手动拼接前缀 - Laravel 需配合
ShouldBeUnique+ 自定义uniqueId()，否则同一任务多次重试可能被去重丢弃 - RabbitMQ 的 TTL + DLX 方案中，DLX 绑定的 key 必须和重试队列声明的 key 一致，否则消息进不了重试队列
死信归档后重放，routing_key 不能复用旧值
从 PostgreSQL 或对象存储捞出历史死信重放时，直接用原 routing_key 推送，大概率触发幂等冲突或状态机错乱。因为原 key 对应的消费者可能已升级逻辑，而旧消息体结构不兼容。
更安全的做法是生成新 key，例如 replay.20260827.chat，并在消息头（headers）里保留原始 key 和 task_id，供下游做血缘追踪或人工核对。
- 不要依赖框架默认的 “重发” 按钮——Laravel Horizon 的 retry 按钮、RabbitMQ Management UI 的 publish message 功能，都默认复用原 key
- 重放脚本必须显式构造新 key，并校验消息体 schema 版本是否在当前消费者支持范围内
- 若业务允许 reopen 旧任务（如工单系统），也应通过 API 显式调用
reopenTask($task_id)，由服务端生成新消息，而不是绕过状态机直接投递
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
