Hyperf 的 hyperf/rocketmq 驱动不支持顺序消息，因其封装仅调用无 MessageQueueSelector 的 send() 方法，无法控制消息路由；需绕过驱动手写 DefaultMQProducer 并显式传 selector，Consumer 端须改用 MessageListenerOrderly 且 Topic 配置为 ORDER 类型。
Hyperf 默认的 hyperf/rocketmq 驱动不原生支持顺序消息，直接调用 produce() 或配置 Producer 无法控制消息路由到指定队列——这是最常踩的坑，很多人卡在这一步就退回原生 SDK。
为什么 hyperf/rocketmq 不能直接发顺序消息
该组件封装的是 RocketMQ 的普通消息发送逻辑，核心是 DefaultMQProducer.send()，而顺序消息必须使用带 MessageQueueSelector 参数的重载方法。驱动里没暴露这个入口，也没提供设置 ShardingKey 或自定义队列选择器的能力。
-
hyperf/rocketmq的Producer::send()内部调用的是无 selector 的 send 方法，消息会轮询投递到所有队列，天然破坏顺序 - 即使你在消息体里手动加
KEYS或shardingKey属性，Broker 不识别，Consumer 也不会按 Key 绑定队列 - 全局顺序（单队列 Topic）在该驱动中也无法强制，因为 Topic 创建、队列数配置、Producer 启动参数都不可控
绕过驱动，手写顺序 Producer 实例
最稳妥的做法是绕过 hyperf/rocketmq 的封装，直接用官方 rocketmq-client 创建 DefaultMQProducer，并显式传入 MessageQueueSelector。注意保持与 Hyperf 生命周期一致（如随进程启动/销毁）。
- 在
config/autoload/dependencies.php中绑定自定义 Producer 类，例如OrderMessageProducer::class - 构造时传入
GroupName和NamesrvAddr，调用start()；务必在onWorkerStart回调中初始化，避免多 worker 复用同一实例 - 发送时用
send(msg, selector, arg)形式，arg通常是业务 ID（如order_id），selector里做arg.hashCode() % mqs.size()路由 - 别忘了在
onWorkerStop里调用shutdown()，否则进程退出时连接不释放
Consumer 端必须用 MessageListenerOrderly
Hyperf 的 Consumer 注解默认走 MessageListenerConcurrently，这会导致即使消息进了同一队列，也会被多个线程并发消费——顺序彻底失效。
- 必须弃用
@Consumer，改用手动注册DefaultMQPushConsumer，并调用registerMessageListener(new MessageListenerOrderly(...)) - 监听器内处理逻辑必须是同步、无锁、短耗时的；若需异步，得把消息内容复制后丢进协程或
ThreadPool，但原始消费线程仍要等回调返回 - 注意
consumeMessage方法返回ConsumeOrderlyStatus.SUCCESS，否则会触发重复投递，破坏局部顺序语义
容易被忽略的部署细节
顺序消息不是写对代码就完事了。生产环境常因配置或集群状态导致短暂乱序，尤其在滚动发布或 Broker 重启时。
- Topic 必须设为
ORDER类型（4.x 集群需在控制台勾选“顺序消息”；5.x 需用mqadmin updateTopic设置-o true） - Consumer Group 的
ConsumeMessageBatchMaxSize必须为 1，否则一批拉多条会跨队列，无法保证单 Key 有序 - 如果用 ACL，
AclClientRPCHook要传给 Producer 和 Consumer 实例，漏掉一个就会鉴权失败静默丢消息
