Webman集成RabbitMQ必须通过外部AMQP客户端库并严格对齐Worker生命周期管理连接；禁止在HTTP请求中新建连接，应于onWorkerStart初始化连接池或独立消费者进程，配置heartbeat、持久化及ACK机制，onWorkerStop务必显式关闭资源。
Webman 本身不内置消息队列能力，集成 RabbitMQ 必须靠外部 AMQP 客户端库 + 手动管理连接生命周期。直接在 HTTP 请求中 new 连接发消息会快速耗尽 socket 资源，这是新手最常踩的坑。
Webman 中不能用 AMQPStreamConnection 每次请求新建连接
Webman 是常驻内存框架，但默认的 HTTP Worker 是短生命周期（单次请求结束即释放），如果在控制器里每次 new AMQPStreamConnection，会导致：
- 连接未 close 就被 GC 回收，RabbitMQ 端积累大量 ESTABLISHED 状态连接，最终触发
too many open files - 连接建立/认证开销大，吞吐量骤降，延迟毛刺明显
- 无法复用连接池，也无法设置心跳保活，容易被中间网络设备断连
正确做法是：在 onWorkerStart 阶段初始化连接，并挂载到全局容器或静态属性上；消费者则需单独启一个 Worker 进程长期监听。
生产者：用 ConnectionPool 管理 AMQPStreamConnection 实例
Webman 支持自定义连接池，推荐封装一个 RabbitMQPool 类，配合 php-amqplib/php-amqplib 使用：
立即学习“PHP免费学习笔记（深入）”；
- 池大小建议设为 CPU 核数 × 2～4，避免过度争抢连接
- 必须设置
heartbeat=30参数，否则空闲连接会被 NAT 或负载均衡器静默断开 -
queue_declare的durable=true和message的delivery_mode=2要配对启用，否则重启 RabbitMQ 后队列或消息丢失 - 不要在
onMessage里直接 publish，应通过$pool->get()->channel()获取通道后操作，用完不 close，归还给池
示例关键片段：
use PhpAmqpLib\Connection\AMQPStreamConnection;
use Webman\Container;
Container::set('rabbitmq.pool', function () {
return new RabbitMQPool([
'host' => '127.0.0.1',
'port' => 5672,
'user' => 'guest',
'pass' => 'guest',
'vhost' => '/',
'heartbeat' => 30,
'pool_size' => 8,
]);
});
消费者：必须用独立 Worker 进程，且手动处理 ACK/NACK
Webman 的 HTTP Worker 不适合做消费者 —— 它没有长轮询机制，也不支持阻塞式 basic_consume。必须另起一个 Worker 类型进程：
- 在
config/bootstrap.php中注册：Worker::add(new RabbitMQConsumerWorker()); - 在
onWorkerStart建立连接和 channel，调用$channel->basic_qos(0, 1, false)控制预取数量，防止单个消费者积压过多消息 - 回调函数内务必显式调用
$msg->ack()或$msg->nack(requeue=true)，否则消息会一直卡在 unack 状态 - 业务逻辑抛异常时，要 catch 并
nack，否则该消息将永远无法重试
ACK 逻辑漏掉是线上最隐蔽的问题之一：表面看消息不断进队、不断“消失”，查日志却无报错，实际是 RabbitMQ 认为它还在处理中。
Workerman 兼容层下，onWorkerStop 必须优雅关闭 AMQP channel
Webman 底层基于 Workerman，所以 onWorkerStop 是唯一可靠的清理时机：
- 不能依赖 PHP 析构函数或
register_shutdown_function，它们在进程被 kill -9 时不会触发 - 要在
onWorkerStop中显式调用$channel->close()和$connection->close() - 若使用连接池，还需调用池的
destroy()方法释放全部连接 - 没做这步，进程重启时旧连接可能残留，RabbitMQ 端显示 connection state = closing，但迟迟不释放
真正稳定运行的关键，不在怎么发消息，而在于连接生命周期是否与 Webman Worker 生命周期严格对齐 —— 少一个 close，就埋一个连接泄漏隐患。
