Kafka 消费 batch 内某条失败时，如何只把该条进死信并继续提交后续位点

【背景】 我们用 Kafka 3.5（3 broker）消费一条库存扣减链路：topic stock-deduct 16 分区，消费组 8 实例，max.poll.records=500。消费逻辑是「读 batch → 逐条扣减 MySQL → 提交 offset」，单条平均耗时约 30ms，一批 500 条约 15s 处理完，平时 lag 基本在 0~50。

【现象 / 卡点】 问题出在「一批里只有某一条失败」：比如第 321 条命中幂等冲突（同一 out_biz_no 重复投递）或外键约束失败抛异常。此时我陷入两难：

1. 整批不提交 offset → 重启 / 再平衡后前 320 条全部重放，只能靠幂等去重兜底，但去重表压力大，且失败那条之后的 322~500 条也被一并重放；
2. 想「跳过失败那条、把它写死信 topic，其余 499 条正常提交」—— 但 Kafka 的 offset 语义是「单分区单调、连续位点」，我没法只提交 0~320 再提交 322~500，中间缺一个 offset 位点就断了。

【已尝试的排查与结果】

• 把 batch 拆小（max.poll.records 从 500 降到 50）：降低了单次重放范围，但放大不了问题，单条失败仍然阻塞整批提交；
• 给失败条单独 catch 后 continue，但 offset 只能提交到「已 poll 的最大位点」，等于把失败那条也提交了 → 变成丢消息，不敢用；
• 想过自己维护一张「partition + offset 处理表」按条提交，但感觉等于重造 Kafka 的 offset 机制，代价很大，没落地。

【期望得到的答案形态】 想请教：在「至少一次投递 + 业务幂等」的语义下，batch 内部分失败时，业界比较稳的工程做法到底是哪种？

• (a) 整批重试 + 幂等去重（接受重复，靠去重表兜底）；
• (b) 逐条 poll（max.poll.records=1）+ 单条死信 + 连续位点提交（牺牲吞吐换精确提交粒度）；
• (c) 自己维护 per-partition 处理位点表，做「乱序提交」；
• (d) 按「连续成功位点」提交 + 失败条进死信，接受失败条之后那段的重复重放。 希望能带上：你们最终选了哪种、为什么、代价是什么（吞吐 / 去重表压力 / 丢消息风险），以及 max.poll.records 具体怎么配、死信 topic 怎么设计。