Confluent.Kafka 是 C# 生态中基于 librdkafka 的高性能 Kafka 客户端；ProducerBuilder 适用于无需 Key 的场景，ProducerBuilder 需确保 Key 非 null；Consume() 必须 try/catch ConsumeException 并监听 OnError 处理 fatal 错误；AutoOffsetReset.Earliest 仅在无有效 offset 时生效；EnableAutoCommit=false 时应在业务持久化后立即 Commit()。
Confluent.Kafka 是目前 C# 生态中对接 Kafka 最稳定、最主流的客户端库。它不是简单封装，而是基于 librdkafka 的高性能绑定，直接暴露底层控制权——这意味着你既能快速上手，也得直面配置细节和错误边界。
ProducerBuilder 和 ProducerBuilder 怎么选？
关键看你的消息是否需要 Key。
- 如果只是发日志、事件通知、无状态任务等，
Key无关紧要（比如不依赖 key 做分区路由或去重），用ProducerBuilder更轻量，序列化开销小，也避免 key 反序列化失败风险 - 如果要用 key 控制分区（如用户 ID → 固定分区保证顺序）、或后续消费者需读取 key，就得用
ProducerBuilder，并确保Key不为 null（否则ProduceAsync会抛ArgumentException） -
Null是 Confluent.Kafka 提供的类型别名，表示“该字段不存在”，不是 C# 的null引用；误写成string却传null值，运行时可能在序列化阶段崩溃
Consume() 必须包在 try/catch(ConsumeException) 里吗？
必须。这不是可选项，是保活底线。
-
Consume()是阻塞调用，但底层网络抖动、broker 临时不可达、SASL 认证过期、甚至 broker 主从切换，都会直接抛出ConsumeException，而不是返回null或超时 - 不捕获会导致消费者线程意外退出，整个消费循环中断，且无日志提示——线上常表现为“悄无声息地停摆”
- 更关键的是 fatal 错误（如
GroupAuthorizationFailed、UnknownTopicOrPartition）：它们不会重复抛出，但 consumer 内部状态已损坏；必须监听c.OnError并主动终止循环，否则会卡死在无效状态，反复重试失败操作
AutoOffsetReset.Earliest 为什么没从头消费？
因为它只在 consumer group 没有有效 offset 时才生效，不是“每次启动都重放”。
- 首次订阅 topic、或手动删除 group metadata（如用
kafka-consumer-groups.sh --delete）、或 offset 过期（offsets.retention.minutes默认 168 小时）后，Earliest才会拉取当前保留窗口内最早的消息（注意：不是 topic 创建以来所有消息） - 只要 group 曾成功 commit 过 offset，后续启动永远从上次位置继续——哪怕你改了代码、重启了服务、甚至换了机器
- 真想强制重放？不能靠改配置。得先调用
c.Unsubscribe()，再c.Subscribe(...)，然后用c.Seek(new TopicPartitionOffset(topic, partition, offset))定位到目标位置（例如Offset.Beginning）
EnableAutoCommit = false 时，Commit() 调用时机怎么把握？
这是最容易引发数据不一致的环节：早了丢数据，晚了重复消费。
- commit 太早（比如刚
Consume()到就Commit()）：业务逻辑还没执行、DB 写入失败、甚至进程直接崩溃，这条消息就永远丢失了 - commit 太晚（比如攒够 10 条再 commit）：若中途崩溃，最多丢 10 条；若业务处理耗时长，还可能触发 rebalance 导致重复分发
- 真实建议：仅在业务逻辑执行完成、且结果已持久化（如数据库事务提交成功、文件落地完成）后，立即调用
c.Commit(cr)；不要跨多条消息批量 commit，除非你明确接受“至少一次”语义下的重复
实际项目里，最难 debug 的从来不是连不上 Kafka，而是 offset 提交时机错位、key 类型误配、或把 ConsumeException 当普通异常忽略。这些点没有魔法开关，全靠配置对齐和防御性编码。
