swoole + kafka 的核心难点是连接生命周期管理、协程安全和错误兜底；90%线上问题源于worker长生命周期导致的kafka连接残留或断连、consume()阻塞协程、以及ack=all下因协程中断导致的消息丢失。
直接说结论：Swoole + Kafka 不是“装个扩展就能跑”的组合，核心难点在连接生命周期管理、协程安全和错误兜底——90% 的线上问题都出在这三块。
为什么 swoole_http_server 里 new Kafka\Producer 会报 connection refused？
这不是 Kafka 没启动，而是 Swoole Worker 进程复用导致的连接残留或提前关闭。PHP-FPM 下每次请求新建连接，而 Swoole 的 Worker 是长生命周期的，Kafka\Producer 实例一旦初始化就绑定到当前协程上下文，但底层 TCP 连接可能被 Broker 主动断开（比如 idle timeout），后续复用时就直接失败。
- 别在
onRequest回调里 new Producer —— 改成单例 + 连接健康检查，每次发消息前调用$producer->getMetadata()简单探测 - 禁用 Kafka 客户端的自动重连（如
reconnect.backoff.ms设为 0），自己用Swoole\Coroutine\Timer::tick()做心跳保活 - Broker 配置里确认
connections.max.idle.ms≥ 应用层心跳间隔，否则服务端先断
Consumer::consume() 在协程里阻塞，导致整个 Worker 卡死
原生 Kafka PHP 客户端（如 rdkafka）的 consume() 是同步阻塞调用，它会一直等新消息或超时，而 Swoole 的协程调度器无法抢占这个 C 层阻塞，结果就是整个协程挂起，Worker 无法处理其他请求。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 必须用
Consumer::consume($timeoutMs)显式传超时，建议 ≤ 100ms，避免拖慢协程调度 - 不要在
onReceive或onRequest里直接调 consume —— 改用Swoole\Coroutine\Channel做消息中转，起独立协程轮询消费，再把消息推入 Channel - 注意
enable.auto.commit设为 false，手动控制 offset 提交时机，否则超时退出时可能重复消费
为什么 acks=all 还丢消息？Swoole 场景下更隐蔽
在 Swoole 环境里，丢消息往往不是 Kafka 配置问题，而是应用层没扛住协程中断。比如 Worker 被 reload、协程被 cancel、或 consume() 返回后业务逻辑 crash，都可能导致消息已取但未处理完就被丢弃。
- Consumer 必须开启
auto.offset.reset=earliest并配合手动 commit，且 commit 前确保业务逻辑成功落库或写入 Outbox 表 - 别依赖
max.poll.interval.ms来防 rebalance —— Swoole 协程里 sleep 或 IO 等待不触发心跳，得用Consumer::commit()或Consumer::pause()主动维持 - 生产者侧，
enable.idempotence=true必开，但要注意它依赖 broker 端transactional.id配置，Swoole 多 Worker 下若共用同一 ID 会冲突
真正难的不是写通代码，而是让每个协程里的 Kafka 连接可观察、可中断、可恢复。很多团队卡在“能跑”和“敢上生产”之间，差的就是连接池状态监控、offset 滞后告警、以及 Consumer 协程异常退出后的 offset 自动回拨机制。
