nats.msgid()仅用于去重，不参与路由；保证顺序需用nats.msgkey()指定业务键，并配合分区流（numpartitions>0）及单goroutine消费同一分区。
Go 中消息顺序性不能靠 goroutine 启动顺序或发送时间保证，必须依赖队列中间件的分区机制 + 客户端显式路由 + 消费端单 goroutine 处理。
为什么 js.Publish() 传 nats.MsgId() 不管用
很多人误以为设置 nats.MsgId("order_123") 就能绑定顺序——它只用于去重（Deduplication），和路由完全无关。JetStream 收到后仍按默认策略分发，同一 OrderId 的消息可能落到不同分区，被不同消费者并发拉取，必然乱序。
-
nats.MsgId()是去重键，不是路由键；启用Deduplication: true时才生效 - 真正影响分区路由的是
nats.MsgKey()，它参与哈希计算并决定消息进入哪个分区 - 流（Stream）必须提前创建并指定
NumPartitions，否则即使传了MsgKey也无分区可路由
kafka-go 发送时必须设 Key 字段，且不能为 nil 或空
Kafka 默认使用 HashPartitioner，但前提是 Message.Key 非空。Key 为空 → 轮询分配 → 同一业务实体消息散落各 Partition → 顺序彻底失效。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 正确写法：
Key: []byte("order_12345")，字符串需转[]byte - 错误写法：
Key: nil、Key: []byte("")、Key: []byte("default")（所有消息挤进同一 Partition） - 别自己算哈希或硬编码
Partition，绕过客户端逻辑易出错且不兼容重平衡
RocketMQ 的 ShardingKey 和 NATS 的 MsgKey 本质一致
都是通过业务主键（如订单 ID）做一致性哈希，把关联消息固定路由到同一 Queue / 分区。但 RocketMQ 需在 Producer 端显式构造 Message 并设置 ShardingKey，NATS 则是调用 nats.MsgKey() 作为 Publish 选项。
- RocketMQ：
msg.SetShardingKey("order_12345")，SDK 内部据此选择 Queue - NATS JetStream：
nats.MsgKey("order_12345")，Broker 根据该 Key 哈希值投递到固定分区 - 两者都要求消费端对每个分区/Queue 使用单 goroutine 拉取消息，否则顺序立即崩溃
消费端并发模型是最大陷阱
哪怕消息已严格按分区有序写入，只要你在消费者里用多个 goroutine 从同一个 chan 或 context 并发读取，顺序就没了。Kafka、NATS、RocketMQ 的 SDK 都不保证多协程读同一分区的消息顺序。
- 正确做法：每个分区启动一个独立 goroutine，内部用 for-range 或阻塞读，串行处理
- 错误模式：
for i := 0; i —— 这会让同一分区消息被多个 goroutine 抢读 - 若需聚合结果，用预分配 slice + 闭包索引写入，避免 channel 排序或 map 竞态
真正的顺序保障不在代码“怎么写”，而在“谁来裁定”：Broker 写入日志的 Offset 才是唯一权威。任何试图靠客户端时间戳、goroutine 启动顺序或网络发送先后去保序的设计，都会在重试、GC、网络抖动面前失效。
