先记住这个答案
commitSync 在提交失败时会阻塞当前线程并按照重试策略重新提交，直到成功或抛出异常（包括重试耗尽或不可重试错误），因此不会产生偏移量缺口。commitAsync 调用后立即返回，失败通过回调暴露，但客户端不自动重试；若后续有更大的偏移量提交成功，会覆盖之前的失败，导致消费者重启后无法重放那些已处理但未提交的消息——这些消息被跳过，可能造成消息丢失；若没有后续成功提交覆盖，重启后则会重复消费。选择需权衡吞吐与可靠性：高吞吐场景常用异步，但需自行处理失败与覆盖风险。
- 同步提交阻塞重试，避免偏移量缺口
- 异步提交不重试，失败仅回调
- 后续提交成功会掩盖之前的失败
提交失败时的两种处理模型
commitSync 会阻塞当前线程直到提交成功或抛出不可重试异常。它依赖客户端内置的重试机制，在遇到可恢复错误时自动重试，因此不会出现提交半途而废。只有确认偏移量已提交，消费循环才继续，这保证了偏移量进度和实际处理严格对齐。
commitAsync 立即返回，提交结果通过回调异步通知。失败时回调可捕获异常，但客户端不重试。若后续有偏移量更大且成功的提交，其会覆盖之前失败的提交。此时失败提交对应的消息虽已处理，但偏移量从未被持久化，一旦消费者崩溃就会从后续成功提交的位置继续，先前已处理但未提交的消息不会被重放，可能造成业务遗漏（消息丢失）。
高吞吐提交下的网络瞬断场景
假设消费者每处理 500 条消息后调用异步提交。某次 broker 发生 2 秒故障，期间 3 次提交失败，但回调仅打印日志。故障恢复后下一次提交成功，覆盖了之前失败的偏移量。若此时消费者重启，会从最新成功位置开始，失败期间已完成处理的消息不会重现，但其中部分业务副作用可能未最终确认。
若改用同步提交，第一次失败会触发重试直到 broker 恢复，期间消费者暂停拉取。虽然吞吐降低，但重启后能从精确位置恢复。这个对比说明同步机制以延迟换取偏移量一致性，异步机制以可能丢失提交记录换取高吞吐。
适用边界与失效条件
同步提交适合对消息丢失极其敏感且能容忍提交延迟的场景，比如支付结算。但它的阻塞特性会拉长单位消息的处理耗时，吞吐随提交频率增加而下降。异步提交适合高吞吐且下游具备幂等性的管道，但必须处理回调失败，不能静默忽略。
同步提交适合对消息丢失极其敏感且能容忍提交延迟的场景，比如支付结算。但它的阻塞特性会拉长单位消息的处理耗时，吞吐随提交频率增加而下降。异步提交适合高吞吐且业务允许一定重复或丢失的场景，下游幂等性可缓解重复，但仍需监控丢失风险，必须处理回调失败，不能静默忽略。
容易答错的地方
- commitSync 总会重试到成功
- 错误理解。它遵循 retries 配置，超过最大重试次数会抛出异常，消费者必须自行停止或降级，否则可能死循环。
- commitAsync 失败没关系
- 后续成功提交只覆盖偏移量，失败时对应的业务副作用若未正确处理，该位置的处理就会被跳过，无法靠重放补偿。
面试官还会怎么问？
如果 commitAsync 失败，如何在回调中安全处理？
常用做法是记录失败并调度一次新的提交，但要注意顺序，避免新提交覆盖其他未完成提交。更稳妥是失败时停止消费并执行同步提交，确保偏移量不跳跃。
能否同时使用 commitSync 和 commitAsync？
可以，但需要注意提交顺序，避免乱序覆盖。通常先尝试异步，失败再同步回退，并确保同一分区内的提交不会并发交叉，建议综合官方文档的管理方式。
在什么情况下选择 commitAsync 更有利？
当业务允许 at-least-once 且消费幂等时，异步提交能显著提升吞吐，因为提交不阻塞拉取循环。若系统已具备幂等去重，重复消费的代价也可控。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。