配置Kafka Consumer的group.id后，enable.auto.commit为false仍自动同步偏移量？

问题现象 #

配置Kafka Consumer的groupId属性后，无论enable.auto.commit设为true还是false，都出现了如下现象：

• 首次运行：轮询获取了0到500的500条消息，未手动执行commitSync()或commitAsync()就停止程序
• 第二次运行：轮询直接获取了500到1000的500条消息

首次运行截图：

第二次运行截图：

现象原因 #

你遇到的情况核心在于Kafka Consumer正常关闭时的默认提交行为：只要程序是正常停止（比如收到中断信号、调用了consumer.close()方法），无论enable.auto.commit配置为true还是false，消费者都会自动提交当前已拉取的位移。这就是为什么第一次运行停止后，第二次启动会从500的位置继续消费。

如果是强制终止进程（比如kill -9），没有触发close()方法，此时不会触发这次自动提交，第二次启动时会根据auto.offset.reset的配置决定消费起始位置（默认从最新消息位置开始，若配置为earliest则从最旧消息位置开始）。

enable.auto.commit的真正作用 #

这个属性的核心是控制轮询过程中的定期自动提交逻辑：

• 当enable.auto.commit=true时：消费者会在后台按照auto.commit.interval.ms（默认5000毫秒）的固定间隔，自动提交当前拉取到的位移。这个提交动作是在poll()方法的执行过程中自动触发的，无需手动调用提交方法。
• 当enable.auto.commit=false时：消费者不会在轮询阶段自动定期提交位移，此时你可以完全手动控制提交时机——比如在确认消息处理完成后，再调用commitSync()或commitAsync()提交位移，以此实现更精准的消费语义（如“至少一次”或“恰好一次”）。若要关闭正常停止时的自动提交，可以调用consumer.close(false)，这样关闭过程中就不会提交位移。

总结 #

• enable.auto.commit的作用是控制轮询阶段的定期自动提交，而非关闭时的提交行为。
• 正常关闭时的自动提交是独立的默认行为，可通过close(false)避免。

内容的提问来源于stack exchange，提问作者Bharathwajan