Workerman消费RabbitMQ必须手动ACK，否则消息易丢失；需设no_ack=false、basic_qos限流、try/catch保障ACK时机，并配合幂等设计防重复处理。
Workerman消费RabbitMQ时，不手动ACK会丢消息
Workerman本身不自动处理AMQP消息确认（ACK），默认是no_ack=true模式——只要RabbitMQ把消息推给Worker，就立刻从队列删掉。一旦Worker进程崩溃、业务逻辑出错或还没处理完就断连，消息就彻底丢了。
真正可靠的消费流程必须显式调用$channel->ack($delivery_info['delivery_tag'])，且只在业务逻辑100%成功后才执行。
- 务必在
onMessage回调里包裹try/catch，失败时调用$channel->nack()并指定$requeue=true - 不要在
onClose或onError里补ACK——消息可能根本没进到你的回调里 - 避免在异步IO（如curl、数据库事务未提交）完成前就ACK，否则等于“假装处理完了”
怎么让Workerman的RabbitMQ消费者支持手动ACK
关键不是改Workerman，而是正确配置php-amqplib的basic_consume参数：把no_ack设为false，并传入$channel实例用于后续ACK操作。
常见错误是直接用get()轮询——它天生不支持手动ACK，只能用basic_consume()配合事件循环。
- 在
onWorkerStart里创建$channel后，调用$channel->basic_qos(0, 1, false)限制预取数量，防止单个Worker积压太多未ACK消息 -
basic_consume的$callback函数必须接收第四个参数$channel，否则拿不到ack()方法 - 示例片段：
$channel->basic_consume('queue_name', '', false, false, false, false, function ($msg) use ($channel) { try { // 处理业务... $channel->ack($msg->getDeliveryTag()); } catch (\Exception $e) { $channel->nack($msg->getDeliveryTag(), false, true); } });
ACK失败导致连接卡死？检查心跳和异常重连
RabbitMQ在收到ACK前会一直持有该消息，并维持TCP连接。如果Worker因超时、内存溢出或PHP致命错误挂掉，又没触发onWorkerStop清理，RabbitMQ会等心跳超时（默认580秒）才释放连接——这期间新消息进不来，旧消息也卡着不动。
- 必须在
onWorkerStart里设置$connection->setHeartbeat(30)，并在Workerman主循环中调用$connection->writeHeartbeat() - 捕获
AMQPConnectionClosedException和AMQPChannelClosedException，在onError里重建$connection和$channel - 别依赖
pcntl_signal做优雅退出——Workerman的stop()不保证等待所有ACK完成，应在onWorkerStop里加usleep(500000)留出缓冲时间
业务幂等性比ACK更重要
即使ACK流程写得再严谨，网络分区、RabbitMQ镜像同步延迟、Consumer重复拉取仍可能导致同一条消息被投递两次。这时候光靠ACK无法解决重复处理问题。
ACK只是保证“至少一次”，而生产环境要的是“恰好一次”语义——这必须靠业务层兜底。
- 消息体里必须带唯一
message_id（建议用uuid_v4），入库或写Redis前先查是否存在 - 避免用时间戳+用户ID拼接作幂等键——高并发下可能碰撞
- 数据库操作优先用
INSERT ... ON DUPLICATE KEY UPDATE或MERGE，而不是先SELECT再INSERT
很多人花一周调通ACK逻辑，却在上线后发现订单被创建了两次——因为没做幂等。这个坑比连接断开更隐蔽，也更难排查。
