先说一个基本判断：在 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 更稳妥。
