直接循环调用basic_publish更慢，因每次调用均触发序列化、网络I/O和Broker队列锁竞争；需用confirm_select+批量publish+wait_for_confirms实现可靠批量发送。
为什么直接循环调用basic_publish反而更慢？
很多人以为“批量发送”就是写个for循环反复调用$channel->basic_publish()，结果发现吞吐量不升反降，甚至比单条还慢。根本原因在于：每次调用都触发一次AMQP协议帧的序列化、网络I/O和Broker端的队列锁竞争。RabbitMQ本身不提供原生的“批量publish API”，所谓“批量”必须靠客户端缓冲+单次网络往返来模拟。
用confirm_select + 批量basic_publish + wait_for_confirms实现可靠批量
这是PHP中兼顾吞吐与可靠性的主流做法：先启用发布确认模式，把多条消息连续发出去（不等待响应），再一次性阻塞等待全部确认。注意，这并非“一条TCP包发多条消息”，而是利用AMQP的流水线机制减少往返延迟。
实操要点：
-
$channel->confirm_select()必须在发送前调用，且每个$channel只能启用一次 - 每条
basic_publish仍需传入完整AMQPMessage对象，不能合并成一个消息体 -
$channel->wait_for_confirms(10)的超时值建议设为秒级（如10），避免无限挂起 - 若返回
false，说明有消息未被Broker确认，需结合get_unconfirmed_count()做重试或日志记录
$connection = new AMQPConnection(['host' => 'localhost']);
$channel = $connection->channel();
$channel->confirm_select(); // 启用确认模式
$messages = [
new AMQPMessage('order_123'),
new AMQPMessage('order_456'),
new AMQPMessage('order_789'),
];
foreach ($messages as $msg) {
$channel->basic_publish($msg, '', 'orders');
}
if (!$channel->wait_for_confirms(10)) {
error_log('Some messages failed to confirm');
}
大批量场景下必须手动分片，避免内存和超时风险
一次性塞几千条消息进缓冲区，容易触发PHP内存限制（memory_limit），或让wait_for_confirms因Broker处理延迟而超时。生产环境应按固定大小分片，比如每100条一组。
立即学习“PHP免费学习笔记（深入）”；
关键判断点：
- 分片大小不是越大越好——通常50~200条/批在大多数网络和Broker配置下较平衡
- 不要在循环里重复调用
confirm_select()，它只需一次 - 每批结束后检查
wait_for_confirms返回值，失败时只重发当前批，而非全量 - 考虑在批处理间加微小延迟（如
usleep(10000)），缓解Broker瞬时压力
别忽略连接与信道生命周期管理
很多人把$channel当全局单例复用，但在长时脚本（如CLI消费者）中，网络抖动或Broker重启会导致信道失效，后续basic_publish静默失败或抛出AMQPChannelException。真正健壮的做法是：每批发送前检查信道是否可用，异常时重建信道。
简单检测方式：
- 捕获
AMQPChannelException或AMQPConnectionException - 不依赖
$channel->is_open()（该方法不一定及时反映真实状态） - 重建信道后必须重新调用
confirm_select() - 避免在Web请求中复用长连接——PHP-FPM进程结束时连接会自动关闭，不必手动
close()
高并发批量发送的难点不在代码行数，而在对AMQP协议流控机制的理解和对PHP运行时边界的敬畏。Broker不会告诉你缓冲区满了，它只会悄悄限速或丢帧；PHP也不会主动提醒你内存快爆了，直到Fatal error。这些地方，得靠日志、监控和分片阈值的反复调优来兜底。
