必须调用 channel->confirm_select() 开启发布确认模式，否则无回调；通过 addconfirmselectcallback 处理 ack/nack；需 wait_for_pending_acks 等待确认，否则丢失响应。
php-amqplib 如何开启发布确认模式
必须在 channel 层显式调用 confirm_select()，否则即使 RabbitMQ 服务端启用了 confirm 模式，PHP 客户端也不会等待确认。这个调用会把当前 channel 切换为 confirm 模式，之后所有 basic_publish() 都变成异步确认流程。
常见错误是只配置了 connection 或漏掉这一步，结果发消息不报错、也不触发回调，看起来像“静默成功”，实际消息可能根本没进队列。
-
confirm_select()必须在channel实例上调用，不能在connection上 - 一个 channel 开启后，所有后续 publish 都受确认约束，无法对单条消息单独开关
- 开启后不能再用该 channel 调用非 confirm 兼容的方法（如某些事务相关操作）
如何监听 confirm 回调并区分成功/失败
php-amqplib 不提供 await-style 的同步等待，而是通过注册 addConfirmSelectCallback() 和 addReturnCallback() 来响应不同事件。真正决定消息是否落地的是 addConfirmSelectCallback() 注册的回调 —— 它会在 broker 返回 ack/nack 后触发。
注意：addReturnCallback() 只在消息被路由失败（比如 exchange 找不到 binding）且 mandatory=true 时触发，它不是 confirm 机制的一部分，别混淆。
- ack 表示消息已写入 broker 的持久化存储（如果配置了 durable）
- nack 表示消息被 broker 拒绝，常见原因包括磁盘满、内存告警、镜像同步失败等
- 回调函数接收两个参数：
$deliveryTag（内部递增序号）和$multiple（是否批量确认）
<pre class="brush:php;toolbar:false;">$channel->addConfirmSelectCallback(
function ($deliveryTag, $multiple) use (&$confirmed) {
if ($multiple) {
// 清除 deliveryTag 及之前所有未确认项
} else {
// 标记 deliveryTag 对应消息为已确认
}
},
function ($deliveryTag, $multiple) use (&$nacked) {
// 处理 nack：重发 or 记录日志 or 推入死信队列
}
);
为什么发完消息立刻 close channel 会导致 confirm 丢失
因为 php-amqplib 的 confirm 回调是基于 AMQP 帧异步处理的，如果在 broker 还没返回 ack/nack 前就调用 $channel->close()
$connection->disconnect()，那些未处理的帧会被丢弃，回调永远不会执行 —— 你既得不到成功反馈，也收不到失败通知。
典型场景是脚本型短生命周期应用（如 CLI 命令或 Web 请求），容易忽略等待确认完成。
- 必须在所有 publish 后，主动调用
$channel->wait_for_pending_acks()或轮询$channel->getUnconfirmedCount() -
wait_for_pending_acks()会阻塞直到所有已发消息收到响应，超时需自行控制（它本身不带 timeout 参数） - 若使用 loop +
wait()，要确保循环能收到 broker 的 confirm 帧（即底层 socket 保持可读）
confirm 模式下的性能与可靠性权衡
开启 confirm 后，每条消息至少增加一次网络往返（broker 返回 ack），吞吐量明显下降。但这是换取投递确定性的必要代价。高频小消息场景下，建议批量 publish + 单次 confirm 等待来缓解。
另一个常被忽略的点是：confirm 只保证消息到达 broker，不保证消费者一定能消费。如果 consumer crash 或 auto-ack 模式下处理中途退出，消息仍会丢失。要端到端可靠，得配合 manual ack + 死信 + 重试策略。
- 不要在高并发 Web 请求中对每条日志都开 confirm；考虑先写本地缓冲，再批量 confirm 发送
- RabbitMQ 3.7+ 支持
confirm.select的no-wait参数，但 php-amqplib 当前版本（v3.5+）未暴露该选项，仍走标准流程 - 如果业务允许“最多一次”，且能容忍少量丢失，confirm 可关；若要求“至少一次”，confirm 是底线，但还不够
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
