消费位点 offset 到底算不算「已处理完成」？要不要把它落进业务库

背景：at-least-once + 消费端幂等已经是社区共识，前面 170 / 51 / 710 / 681 那几篇把幂等表、业务状态机聊得够透。但还有一个更底层、更少被认真掰扯的分歧：offset 提交这个动作，到底代表什么？

我的理解是：offset 只表达「这条消息被读出来、执行走到了 commit 那一步」，它既不等于「业务副作用已落库」，更不等于「下游已能观察到」。可现实里太多团队把 offset 当成了"处理完成"的凭据——监控看 lag、对账看 offset、故障恢复从 offset 重放，全押在它身上。于是埋下三类坑：

1. 处理逻辑里「写业务表」和「提交 offset」是两步，中间崩溃 → 要么重放（重复），要么极端情况下 offset 先提交（丢失）；
2. 幂等表挡不住「业务表写成功但 offset 没提交」的窗口：重放时幂等键命中了，可你真正想确认的是"业务到底做没做"，这两件事并不等价；
3. 死信 / 重放工具默认按 offset 回退，等于把"没处理完"直接当成"已处理"给回滚掉了。

常见分歧（三种做法）：

• 派 A（别落库）：offset 是 broker 的元数据，语义就是"读到哪"，硬塞进业务库等于把两种状态混在一起，出事故反而更难排查；幂等表 + 状态机已经够了。
• 派 B（要落库）：把 offset / 消费进度和业务状态写进同一事务，才能保证「业务做了 = 进度前进了」，这才是消费端真正的一致性边界。
• 派 C（折中）：offset 不直接落业务库，但消费进度单独建一张 progress 表，和业务表同库同事务提交；lag 监控和重放都基于这张表，而不是 broker 的 offset。

我的倾向：偏 C。理由——offset 本身不该承担业务语义，但"我消费到第几条"这个事实值得用一张和业务同库同事务的 progress 表来"背书"：崩溃恢复时以 progress 为准判断要不要重放，幂等表负责挡重复副作用，三者各司其职、互不替代，而不是让 offset 一个概念背三份职责。

想听大家：你们团队消费端的 offset 是只信 broker，还是落了 progress 表？在「写业务表 + 提交 offset」两步之间崩溃的真实案例里，你们实际是偏重复还是偏丢失、又怎么兜的？分区级还是实例级提交，有没有踩过"某分区卡住但整体 lag 看着正常"的坑？