利用Composer库构建PHP原生消息队列的高可靠传输层

先说一个基本判断：在 PHP 生态里，php-amqplib 确实是构建 RabbitMQ 传输层最成熟、最可靠的 Composer 库。它不是什么“原生队列”，但用纯 PHP 就能实现高可靠的消息收发——关键不在于语言是否原生，而在于协议层是不是够可靠、ACK 是否可控、连接能不能恢复。

如果你只是写几行 basic_publish，那谁都会。但要让每条消息在进程崩溃、网络闪断、RabbitMQ 重启后仍然不丢——这就得靠你把 durable、delivery_mode、ack、heartbeat、version lock 全部对齐，缺一不可。下面挨个拆开说。

RabbitMQ 连接必须显式启用持久化与确认机制

默认的连接和发布行为，其实非常容易丢消息。举个例子：如果队列没声明 durable，服务端一重启队列就没了；消息发布时没设 delivery_mode => 2，那消息根本不落盘；消费者崩溃前如果没做 ack，那条消息就永远消失了。怎么解决？

• $channel->queue_declare('my_queue', false, true, false, false) —— 第三个参数 true 就是 durable，必须设。
• 发布消息时：new AMQPMessage($body, ['delivery_mode' => AMQPMessage::DELIVERY_MODE_PERSISTENT]) —— 否则消息只存在内存里。
• 消费者端一定要在业务逻辑真正执行完后才调用 $channel->basic_ack($msg->getDeliveryTag())。
• 连接断开时，AMQPStreamConnection 不会自动重连。你需要自己封装重试逻辑——比如用 while (true) + sleep(1) + 异常捕获。

composer.json 中的版本约束直接影响 ACK 行为兼容性

php-amqplib/php-amqplib 在 v3.x 和 v4.x 之间有个关键差异：v4+ 默认启用了 publisher confirms（服务端回执），而 v3.x 需要手动开启；v4+ 的 basic_publish 返回值含义也变了。如果你项目锁死 "php-amqplib/php-amqplib": "^3.6"，却按 v4 文档的写法去调用，那就静默失败了。几个建议：

• 生产环境务必固定 minor 版本，比如 "php-amqplib/php-amqplib": "3.6.3"，避免自动升级引入行为变更。
• 检查 vendor/php-amqplib/php-amqplib/CHANGELOG.md，重点关注 “Breaking changes” 和 “Publisher confirms” 相关条目。
• v4+ 如果启用了 confirms，需要配合 $channel->wait() 或异步回调，否则可能阻塞或漏等确认。

超时与心跳配置不当会导致连接被 RabbitMQ 主动踢出

RabbitMQ 默认 60 秒无心跳就断连，而 php-amqplib 默认心跳是 0（禁用）。一旦网络抖动或消费者处理慢，连接会在你毫无感知的情况下中断，后续 basic_publish 直接抛 AMQPConnectionClosedException——可多数人根本没 catch。正确的做法：

• 初始化连接时必须显式传心跳：new AMQPStreamConnection('localhost', 5672, 'guest', 'guest', '/', [], 3.0, 60)——最后两个参数分别是 timeout 和 heartbeat（单位秒）。
• heartbeat 值建议设为 30～45，不能大于 RabbitMQ 配置的 heartbeat（可以查 rabbitmqctl environment 或 config 文件）。
• 不要依赖默认 timeout（3.0s 太短）。高负载下 publish 可能超时，根据消息体大小和网络情况调到 5～10s 更稳妥。