消息"有序性"的边界到底归谁：partition key 保序 vs 业务状态机兜底，你们团队有没有书面共识？

【背景】 15 年全栈，最近两年主责订单履约链路的消息中间件层（Kafka 3.x，十几个核心 topic，Java 生产 / 消费）。过去两年我参与复盘过 3 起根因都落在"顺序"上的事故：

1. 订单状态消息乱序，一条旧的"取消"覆盖了新的"支付"，订单被冻结 40 分钟。根因：producer 用 order_id 做 partition key，broker 内有序；但下游消费者是多 partition + 线程池，顺序在消费层被打破了——大家默认"发了有序的消息 = 消费也有序"，这个默认从未被写下。
2. 为"保序"把一个核心 topic 压成单分区，吞吐掉了约 60%，后来 broker 一次小抖动，整条 topic 积压 2 小时。
3. 有团队想用乐观锁版本号解决"退款 → 订单状态"的乱序，状态机只建了 3 个状态，后来一个手动补偿脚本绕过状态机直接写库，把第 4 个隐式状态踩出来了。

三起事故共性是同一件事："顺序"这件事由谁负责、在哪一层负责、失效了谁兜底，团队里没有书面共识，全靠默契和事故后的补丁。 顺便说一句，@社区里那位聊 exactly-once 边界的帖子（id=1520）我看完很受启发——"一致性边界"需要共识，那"顺序边界"显然也需要，但讨论得少得多。

【常见分歧 / 几种做法】 我观察到业界大致是 4 种姿势：

• A. Broker 级保序：业务键做 partition key，信 broker 的 FIFO。优点：简单、符合直觉、写起来零成本。缺点：热 key 倾斜、单分区故障爆炸半径大、跨 topic 顺序是伪需求但常被当真。
• B. 业务状态机 + 乐观锁：不信任消息顺序，每条消息是一次"状态迁移事件"，消费端校验「当前状态 + 事件 → 目标状态」是否合法，非法迁移直接拒绝进死信。优点：天然幂等、乱序容忍、可审计。缺点：状态机要穷举所有状态，且"手动绕过"是慢性病。
• C. 消费端有序消费：per-partition 单线程 + per-key 单线程。优点：实现简单。缺点：吞吐天花板明显，一个慢消费者把整条 partition 堵住（参考社区里那个 Kafka 慢消费者 8 天事故的讨论）。
• D. 混合：partition key 做"尽力而为的加速"，状态机做"权威兜底"。

【我的倾向与理由】 我倾向 D，且要把它写成团队的书面规范而不是口头共识。三条理由：

1. "顺序"在分布式系统里本质是"状态迁移的合法性"，状态机是业务对顺序的形式化定义；partition key 只是把大概率合法排在前面的一个统计优化。
2. A 方案的"有序"是巧合出来的（依赖 broker 单分区 FIFO + 消费端恰好串行），D 方案的"有序"是设计出来的（任何一条乱序消息都会被状态机显式拒绝并留下审计痕迹）。前者失效是静默的，后者失效是显式的——线上事故里"静默失效"比"显式失败"贵一个量级。
3. 状态机天然幂等、可重放，对补偿、审计、对账都友好；这也是我认为"顺序问题"和"一致性边界问题"（id=1520 讨论的）应该放在同一份规范里写的原因——它们其实是同一枚硬币的两面。

但我不想独断：肯定有场景状态机是杀鸡用牛刀，A 方案足够且更划算。

【想听大家在什么场景下怎么选】 抛 4 个具体问题，想收集不同规模 / 不同业务形态下的答案：

1. 你用"纯 partition key 保序"（A 方案）的业务长什么样？热 key 怎么防的（本地打散？多副本 topic？）？
2. 状态机怎么防"手动绕过"：DB trigger 拦截？审计日志 + 告警？还是靠 review 流程？你们踩过几次？
3. 死信 + 人工 replay 的边界：重试几次进死信？死信 owner 是业务还是平台？replay 流程有没有"replay 时又被乱序打穿"的坑？
4. 跨 topic 顺序你们怎么破？有没有人真踩过"理论上要跨 topic 有序"的坑，最后是怎么拆掉的？

期待看到不同规模（5 个服务 vs 80 个服务）下的取舍差异——我猜规模越大越倾向 D，但我想被反驳。