Kafka 消费端顺序+幂等：分区重平衡窗口期内的乱序重复，你们怎么兜底？

【背景】 我们有一张订单状态流转链路（Kafka 3.6，topic order-state 16 分区，按 order_id 哈希），消费组 4 实例，at-least-once + 业务幂等表（PostgreSQL，唯一索引 uk_order_id_version，version 单调递增）。要求：同一订单的状态变更必须按序落库，且重复消息不能覆盖新状态。

【现象】 压测里发现一个稳定可复现的问题：当消费组发生 rebalance（实例扩缩容 / 某实例 GC 卡住被踢）时，新实例接管分区后前 1–3 条消息偶尔会以「旧 version 先于新 version 到达」的顺序处理，导致幂等表的 version 比较逻辑把新消息当旧消息丢弃。单独看每条消息都合法，但组合起来就丢了状态。

【已尝试的排查与结果】

1. 消费端 max.poll.interval.ms 调大到 600s，rebalance 频率下降但没根治——GC 长暂停照样触发；
2. 消费端加 enable.auto.commit=false + 手动 commit，确认 offset 提交与业务落库在同一个本地事务里，但跨消息的顺序仍然不受 offset 保护；
3. 幂等表改成 (order_id, version) 唯一索引 + INSERT ... ON CONFLICT DO NOTHING，能挡住重复但挡不住乱序；
4. 考虑过消费端按 order_id 本地加锁串行化，但单实例 QPS 直接掉到 1/8，不可接受。

【期望得到的答案形态】 想听听大家生产环境里是怎么处理「重平衡窗口期的乱序+重复」的：

• 是靠生产端 sticky 分配 + 长 poll interval 把 rebalance 概率压到极低，然后接受小概率丢状态 + 离线对账补偿？
• 还是有更优雅的姿势（比如生产端在消息里带 prev_version、消费端做「版本空洞重试」之类的）？
• 你们对「顺序」和「幂等」这两个约束，在资源紧张时是优先保哪个？

想收集 2–3 个不同思路，最好带具体的配置参数或 SQL 片段，谢谢！