Kafka 消费组 rebalance 后 lag 飙升且持续 30s+，手动提交位移能治本吗

【背景】 我用 Kafka 2.8（3 broker）承接订单履约事件流，topic 64 分区，消费组 12 实例，consumer 配置：session.timeout.ms=10s、heartbeat.interval.ms=3s、max.poll.interval.ms=300s、enable.auto.commit=true（默认 auto.commit.interval.ms=5s）。单条消费是「查库 + 写 ES + 调下游」，P99 约 400ms，日均 800 万条。

【现象】 最近一周监控（Lag 用消费组 offset - 分区 end_offset 计算）显示：每当触发 rebalance（通常是实例发版滚动或某实例 GC 触发 session 超时），lag 会瞬间冲到 20~80 万，然后需要 30~90 秒才逐步回落。更糟的是期间有约 0.3% 的消息被重复消费（下游按业务主键幂等，但 ES 里有重复 doc 残留）。

【已尝试的排查】

1. 把 max.poll.records 从默认 500 调到 50，rebalance 间隔没有明显变化；
2. 把 session.timeout.ms 从 10s 调到 30s、heartbeat 调到 10s，rebalance 频率略降但 lag 尖峰依旧；
3. 怀疑 auto.commit 在 rebalance 时把未消费完的位移提交了，考虑改成 enable.auto.commit=false + 手动 commitSync，但不确定会不会把「至少一次」变成「恰好一次」，或者反过来放大重复窗口；
4. 看了 broker 端 GC，broker 侧正常；客户端实例的 Full GC 日志显示发版期间有 1~2 次 800ms+ 的停顿。

【期望得到的答案形态】 希望有同学能从「rebalance 触发 → 位移提交策略 → 重复窗口大小」这条链路讲清楚：a) 手动提交位移的正确姿势（commitSync vs commitAsync、提交时机）；b) 在 64 分区/12 实例这种规模下，rebalance 期间 lag 尖峰是否属于正常现象，有没有量化经验值；c) 重复消费窗口到底由哪些参数决定，怎么把 0.3% 压到 0.1% 以下。最好能给出可直接抄的 consumer 配置片段，以及一条可复现的验证步骤（比如用 kafka-consumer-groups 看位移变化）。