我会先确认影响范围，同时控制故障继续放大。从紧急止损、Lag 定位、并行扩容到数据恢复系统处理 Kafka 消息积压。先确认堆积范围、增长速度和业务影响并停止流量放大，再区分生产突增、消费者异常、处理变慢、分区倾斜或下游瓶颈；短期通过恢复消费者、限流和增加有效并行度止损，长期通过容量规划、批量处理、背压和降级机制防止复发。

止损之后，我会按请求链路建立证据，而不是凭经验猜。 records-lag-max：分区最大积压。 consumer-fetch-manager-metrics：拉取与消费速率。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

定位时我最关注这些参数、指标和容量关系。先确认堆积范围、增长速度和业务影响并停止流量放大，再区分生产突增、消费者异常、处理变慢、分区倾斜或下游瓶颈；短期通过恢复消费者、限流和增加有效并行度止损，长期通过容量规划、批量处理、背压和降级机制防止复发。

找到根因后先做最小修复，再用同样的流量验证。消费者扩容后数据库连接池已饱和，更多实例只增加等待，净消费能力未提升。优化批量写、提高分区并按数据库可承载并发设置消费者后，才形成正的追赶速率。 总 Lag 掩盖单分区热点：各分区 Lag：先恢复正净速率。 无限重试毒消息阻塞分区：生产/消费净速率：隔离毒消息。 扩容消费者压垮下游：单批处理时长：扩容不超过分区/下游容量。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「净消费速率」为主基线，记录值应满足「记录分区基线」；同时保存 各分区 Lag、生产/消费净速率，使后续变化能够回到同一时间轴比较。

恢复阶段要逐步放量，最后把监控和边界补齐。积压恢复必须同时保证正确性；跳过、改 offset 或扩大批次都要明确重复、丢失和乱序的补偿方式。