kafka生产者send()方法非阻塞但存在隐式同步点，细粒度错误捕获唯一可靠方式是callback机制；它在sender线程异步执行，可精准获取真实发送结果与元数据，需配合retries=0、acks=all等配置才能暴露底层异常。
Kafka 生产者调用 send() 方法本身是非阻塞的，但“非阻塞”不等于“无同步点”——它只是不等消息真正发到 Broker，而会在关键环节隐式等待，比如首次或元数据过期时拉取 Topic 元数据。真正实现细粒度错误捕获，靠的是 Callback 机制，它在 Sender 线程中异步执行，能拿到最真实的发送结果。
Callback 是唯一可靠的失败感知入口
Callback 不在主线程执行，而是在 Kafka 内部的 Sender I/O 线程中触发，此时消息已尝试发送并收到 Broker 响应（或超时/网络异常）。这意味着：
- Callback 中的
exception非 null，代表消息确实未写入 Broker（如 Leader 不可用、分区离线、序列化失败、acks 超时等）； - Callback 中的
metadata仅在成功时有效，含 partition、offset、timestamp 等真实落盘信息； - 不能依赖
send()返回的Future来做细粒度判断，因为get()会阻塞，且异常类型更粗（比如TimeoutException可能掩盖底层NotLeaderOrFollowerException）。
必须配合关键配置才能暴露底层错误
默认配置下部分错误会被静默重试或吞掉，需显式调整：
-
retries = 0：避免重试掩盖原始错误（如
UnknownTopicOrPartitionException）；若需重试，应在 Callback 中自行判断再重发； -
max.block.ms = 1000：限制元数据拉取阻塞时间，防止
send()卡死在第一步； -
delivery.timeout.ms = 120000（Kafka 2.6+）：统一控制从入队到回调的总时限，比
request.timeout.ms+ 重试更可控； - acks = all：确保收到 ISR 全部副本确认，让 Callback 中的失败更贴近真实持久化失败。
Callback 内部要区分错误类型并做针对性处理
常见底层异常及其含义：
-
TimeoutException：Broker 未在request.timeout.ms内响应，可能是网络抖动或 Broker 过载； -
UnknownTopicOrPartitionException：Topic 不存在或分区数变更未及时同步，需检查元数据刷新逻辑； -
NotLeaderOrFollowerException：目标分区 Leader 切换，Sender 会自动重试，但 Callback 中出现说明重试也失败了； -
SerializationException：key/value 序列化失败（如 null 值但 serializer 不允许），属于客户端逻辑错误； -
RecordTooLargeException：单条消息超过max.request.size或 broker 的message.max.bytes，需拆分或压缩。
别忽略 send() 后的“假完成”陷阱
代码里 send(..., callback) 后立刻打印 “after”，不代表消息已发出去，只表示它进了缓冲区（RecordAccumulator）或元数据已就绪。真正成败，只在 Callback 里见分晓。所以：
- 日志记录、监控埋点、告警触发，都应放在 Callback 内，而非 send() 后；
- 不要在 Callback 外做“发送成功”的业务假设（例如删本地缓存、更新状态），否则可能误判；
- 若需严格顺序或强一致性，需结合幂等 Producer（
enable.idempotence=true）和事务，Callback 仍是唯一可观测入口。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
