max.poll.interval.ms 是两次 poll 间隔上限，非单条消息处理超时；需同步校准 session.timeout.ms（建议设为前者的1/3）和 heartbeat.interval.ms（须小于 session.timeout.ms/3），否则易触发误 rebalance 或启动失败。
max.poll.interval.ms 不是“处理超时阈值”，而是“两次 poll 间隔上限”
它不监控单条消息耗时，也不管你 processRecord() 花了 2 秒还是 20 秒——只看从上一次 poll() 返回，到下一次 poll() 调用之间过了多久。中间哪怕全是 Thread.sleep(10000) 或数据库 INSERT 阻塞，只要总间隔超了这个值，协调器就发 LeaveGroup，强制 rebalance。
所以调大它不能“防止阻塞”，只是把“误判死亡”的时间点往后推；真正要防误踢，得让两次 poll() 之间的空窗可控。
怎么设才不踩坑：必须同步校准 session.timeout.ms 和 heartbeat.interval.ms
这三个参数是联动的，单独改 max.poll.interval.ms 很可能启动失败或心跳失效：
-
heartbeat.interval.ms必须 小于session.timeout.ms / 3（Kafka 3.3+ 要求更松，但仍建议遵守） -
session.timeout.ms必须 ≤max.poll.interval.ms（新版本），且推荐设为后者的1/3左右，例如max.poll.interval.ms=30000→session.timeout.ms=10000 - 如果只调大
max.poll.interval.ms却没调session.timeout.ms，消费者会报错：Invalid value 60000 for configuration max.poll.interval.ms: Expected a value no larger than 30000
业务处理慢时，光调参数不如拆逻辑
比如你一批拉 500 条，每条调一次 HTTP，平均 80ms，整批就要 40 秒——这时设 max.poll.interval.ms=60000 是治标；更稳的做法是：
- 把同步 HTTP 改成批量提交或异步
CompletableFuture，避免线程卡死 - 用
max.poll.records=50缩小单批量，把 500 条分 10 次拉，每次处理更快、更可控 - 在
poll()后立即启动独立线程池处理记录，主线程尽快回到下一轮poll()，保证间隔不超标 - 别依赖
auto.commit=true，手动控制 offset 提交时机，避免 commit 延迟拖累 poll 间隔
超过 5 分钟还搞不定？说明不是配置问题，是架构瓶颈
如果你发现必须把 max.poll.interval.ms 设到 300000（5 分钟）以上才能不 rebalance，基本可以确定：
- 消费逻辑里有强串行、不可拆分的长任务（如单次导出全量报表）
- IO 瓶颈严重（比如直连慢库、没连接池、没索引）
- GC 频繁或堆内存不足，导致线程停顿（查 GC 日志里的
pause时间）
这时候再调参数只是掩耳盗铃——重平衡延迟变长，故障发现变慢，下游积压更难感知。该切分任务就切分，该加资源就加资源，别拿超时参数当万能胶带。
