Confluent.Kafka ConsumerBuilder 必须指定 GroupId，否则无法加入消费组、不分配分区、收不到消息；GroupId 是 offset 管理和 rebalance 协调的唯一标识，即使单实例调试也需设置临时值。
Confluent.Kafka 是目前 C# 生产环境里最稳、最主流的 Kafka 客户端，不是“可用”，而是“应该用”。其他封装库要么已停更，要么不支持 AdminClient、动态重平衡、精确一次语义（EOS）等关键能力。
为什么 Confluent.Kafka 的 ConsumerBuilder 必须指定 GroupId
没设 GroupId 的消费者无法加入消费组，也就没法自动分配 partition，结果是：启动成功但永远收不到消息。Kafka 不会报错，只会静默跳过 assignment 流程。
-
GroupId是消费组的唯一标识，Kafka 依赖它做 offset 管理和 rebalance 协调 - 同一
GroupId下多个实例才能实现负载分摊；不同GroupId则各自全量读取（适合审计、备份等场景） - 若只想单实例消费且不提交 offset（比如调试用），仍需设一个临时
GroupId，否则consumer.Subscribe()后调用Consume()会一直阻塞或超时
AutoOffsetReset 设成 Earliest 还是 Latest？
这取决于你是否要处理历史积压数据。设错会导致消息“凭空消失”——不是丢了，是你根本没读到。
-
AutoOffsetReset.Earliest：消费者首次启动时，从 topic 最老 offset 开始读（适合补数、初始化） -
AutoOffsetReset.Latest：只读启动后新写入的消息（适合实时告警、监控流） - 注意：这个参数只在 consumer 没有已提交 offset 时生效；一旦 commit 过 offset，后续重启就完全按已存 offset 继续，
AutoOffsetReset不再起作用
手动提交 offset 为什么比自动提交更可靠？
默认 EnableAutoCommit = true 时，Kafka 每隔 AutoCommitIntervalMs（默认 5s）自动提交一次当前 offset。但业务逻辑可能还没执行完，就提前提交了——导致消息丢失。
- 典型问题：收到消息 → 解析 JSON → 调用下游 HTTP 接口 → 接口失败重试中 → offset 已提交 → 进程崩溃 → 消息永久丢失
- 正确做法：关掉自动提交（
EnableAutoCommit = false），在业务逻辑彻底完成后再调用consumer.Commit() - 注意：
Commit()是同步阻塞操作，高频提交会影响吞吐；建议批量处理后统一提交，或用CommitAsync()配合重试逻辑
ProducerConfig 中 BootstrapServers 写错端口会怎样？
常见错误是写成 "localhost:2181"（ZooKeeper 端口）或 "localhost:9093"（SSL 端口但未配 SSL）。结果不是连接拒绝，而是卡在 DNS 解析或 TCP 握手阶段，超时时间长达 30–60 秒。
- Kafka broker 默认监听
9092（明文）或9093（SSL），必须跟SecurityProtocol配置一致 - 本地开发用
localhost:9092前，确认server.properties中listeners=PLAINTEXT://:9092且advertised.listeners正确（Docker 环境尤其容易错） - 生产环境务必用域名或 VIP，避免硬编码 IP；
BootstrapServers可填多个，用逗号分隔，客户端会自动探测可用节点
offset 提交时机、GroupId 生命周期、broker 地址与协议匹配——这三个点，只要一个没对齐，消费者就会“看似运行，实则失联”。它们不报错，也不打日志，只默默跳过消息。这是 C# 接入 Kafka 时最常被忽略的静默陷阱。
