Webman集成RabbitMQ真正稳定可靠的关键在于连接池合理配置、手动ACK+幂等+死信兜底、延迟插件校验、Worker优雅关闭及vhost隔离。需按Worker数×1.5设min_connections，max_connections≤200，wait_timeout≤3秒；consume中try/catch/finally确保ack；启用publisher-confirms和mandatory；延迟功能须确认rabbitmq_delayed_message_exchange插件已启用；onWorkerStop中调用close()并sleep(1)；每个vhost单独配置连接池。
Webman 集成 RabbitMQ 要想真正稳定可靠，关键不在“连得上”，而在“断得了、重得好、不丢、不重、扛得住压”。光靠 composer require workbunny/webman-rabbitmq 装完就跑，线上撑不过三天。
连接池配置不合理导致 Channel 耗尽或阻塞
默认的 connections_pool 配置（如 min_connections=1, wait_timeout=10）在高并发消费场景下极易触发影子模式下的通道等待，而 wait_timeout 设太大，Worker 会卡住；设太小，又频繁抛出 ConnectionPoolTimeoutException。
-
min_connections建议按 Worker 进程数 × 1.5 设置（例如 8 个 Worker，起始配 12），避免冷启动争抢 -
max_connections不宜超过 RabbitMQ 单节点推荐连接上限（通常 1024，但建议控制在 200 以内） -
wait_timeout必须 ≤ 3 秒，否则会拖慢整个事件循环；配合idle_timeout=60防止空闲连接堆积 - 每个
Builder实例应绑定独立连接池，避免跨业务混用（比如订单队列和日志队列共用一个池）
消息确认与重试逻辑没兜底，导致重复消费或消息丢失
Webman-RabbitMQ 默认启用自动 ACK，一旦消费者进程崩溃或处理超时，消息就永久消失。手动 ACK 又容易漏调 $message->ack() 或误调 $message->nack(requeue=true)，造成无限循环重投。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 必须在
consume回调里用try/catch/finally包裹业务逻辑，ack()只在finally中调用（且仅当处理成功） - 对可能失败的操作（如 HTTP 调用、DB 写入），先本地记录状态再发消息；消费端查状态做幂等，而非依赖 RabbitMQ 的重试
- 禁用
requeue=true，改用死信队列（DLX）+ TTL 路由到重试队列，避免原队列被刷爆 - 生产者端开启
publisher-confirms和mandatory，捕获UnroutableMessageException和确认失败回调
延迟队列依赖插件但未校验环境，上线即报错
workbunny/webman-rabbitmq 的延迟功能底层依赖 RabbitMQ 的 rabbitmq_delayed_message_exchange 插件。Docker 启动时若没显式启用，或生产环境用的是旧版（declareExchange 会直接抛 ChannelException: NOT_FOUND。
- 部署前必须执行：
docker exec -it rabbitmq rabbitmq-plugins enable rabbitmq_delayed_message_exchange - 代码中声明延迟交换机时，加
if (! $channel->exchange_exists('delayed.exchange')) { ... }容错判断 - 不要把延迟时间写死在路由键里（如
order.delay.30s），改用消息头x-delay，由插件统一解析 - 测试阶段用
rabbitmqctl list_plugins确认插件状态，CI 流水线加入该检查步骤
Worker 生命周期与连接未对齐，重启时消息中断
Webman 的 onWorkerStop 钩子默认不等待消息处理完成就关闭 Channel，正在处理的消息会被强制中断，既没 ack 也没 nack，变成“不可见但未确认”状态，直到消费者超时释放才重回队列——这期间可能长达 30 分钟（取决于 consumer_timeout）。
- 在
onWorkerStop中主动调用$builder->close()并sleep(1)等待通道关闭完成 - 给每个
Builder设置consumer_timeout=10（秒），避免单条消息卡死整个 Channel - 使用
supervisor或systemd管理 Worker 进程时，stopwaitsecs必须 ≥ 15，留足消息收尾时间 - 禁止在
onWorkerStart中做耗时初始化（如拉配置、建 DB 连接），应改用懒加载或预热 Worker
最易被忽略的是虚拟主机（vhost）权限和连接复用边界：同一个 Connection 实例不能跨 vhost 复用，而 workbunny 的连接池默认不校验 vhost 一致性，配置写错会导致静默失败——现象是消息发不出去，但日志里连错误都不打。务必在 connections.php 里为每个 vhost 单独定义连接配置块，并在 Builder 初始化时显式指定 connection_name。
