RabbitMQ消息丢失与PHP版本无关，根源在于AMQP契约未满足：exchange和queue必须显式设durable=true，消息需deliveryMode=2，publish须启用confirm模式并等待ACK，mandatory=true配合returns回调捕获路由失败。
PHP 8.5.5 本身不会导致 RabbitMQ 消息丢失；问题一定出在 php-amqplib 的用法、配置或与 Broker 的契约对齐上。RabbitMQ 不认 PHP 版本，只认 AMQP 协议行为和持久化开关是否打开。
确认队列是否真正 durable=true
PHP 中声明队列时，durable 参数必须显式传入 true，否则默认是 false（内存队列）。很多开发者误以为“队列存在”就等于“持久”，其实不然。
-
$channel->queue_declare('my_queue', false, true, false, false)—— 第三个参数才是durable，不是第二个 - 用
rabbitmqctl list_queues name durable验证输出中对应队列的durable列是否为true - 若用 Laravel Horizon 或 Symfony Messenger，默认队列名可能带随机后缀（如
amq.gen-xxx），这类队列天生durable=false，重启即消失 - 队列声明必须在生产者和消费者**首次连接时就执行**，不能只靠某一方声明——Broker 不会自动补全缺失的持久化属性
检查 exchange 是否 durable，否则路由失效
队列再持久也没用：如果绑定的 exchange 是临时的（durable=false），Broker 重启后 exchange 消失，所有 routing key 匹配失败，新消息直接被丢弃，且无日志提示。
-
$channel->exchange_declare('my_exchange', 'direct', false, true, false)—— 第四个参数是durable - 用
rabbitmqctl list_exchanges name type durable查看目标 exchange 的durable是否为true - PHP 默认不设
durable，所以几乎总是false，这是最常被忽略的断点 - 交换机未持久 → 队列持久化 → 消息发不出 → 表现为“消息消失”，但
basic_publish()仍返回成功
避免 php-amqplib 的非阻塞 publish 导致静默失败
php-amqplib 默认使用 AMQP_NO_WAIT，basic_publish() 调用后立即返回，不等 Broker 确认。网络抖动或 channel 关闭时，消息实际没发出去，但 PHP 代码毫无感知。
立即学习“PHP免费学习笔记（深入）”；
- 必须调用
$channel->confirm_select()开启 confirm 模式 - 发完消息后，必须显式调用
$channel->wait_for_pending_acks()或监听on_confirm回调 - 若跳过这两步，即使
basic_publish()返回true，也不能说明消息抵达 Broker - 配合
mandatory=true和returns回调，才能捕获“到达 Broker 但无匹配队列”的情况
PHP 进程生命周期导致的队列状态错乱
PHP-FPM 或 CLI 脚本执行完就释放 channel/connection，若队列声明写在业务逻辑里（而非启动时一次性完成），每次请求都重新 declare，可能触发 PRECONDITION_FAILED 错误，导致后续操作静默失败。
- 队列/交换机声明应放在长连接初始化阶段（如 Laravel 的
QueueServiceProvider或独立守护进程 startup） - 不要在每个 HTTP 请求里重复
queue_declare()，尤其当参数不一致时（比如一次durable=true，下次false） - CLI 消费者若未设置
declare的passive=true标志，首次运行后重启会因队列已存在而报错退出 - 用
rabbitmqctl list_bindings看绑定是否真实存在，而不是依赖代码“应该有”
真正要盯住的不是 PHP 版本，而是每一层 AMQP 契约是否被满足：exchange durable、queue durable、message deliveryMode=2、confirm_select + wait_for_pending_acks、mandatory + returns callback。少一个，消息就在那个环节无声蒸发。
