php-amqplib 是 PHP 接入 RabbitMQ 最主流选择，需确保服务运行、权限配置、端口开放、vhost 存在；生产环境必须持久化消息（delivery_mode=2）、队列及交换机，消费者须独立守护进程+手动确认，消息体推荐结构化数组并校验 JSON。
php-amqplib 是当前 PHP 接入 RabbitMQ 最主流、最稳妥的选择。它纯 PHP 实现，不依赖 amqp 扩展，部署兼容性好，且已稳定维护多年（v3.x 支持 PHP 8.0+）。直接用它，比折腾扩展或自研 TCP 封装更省心。
如何确认 RabbitMQ 服务可用且权限正确
很多“连接失败”其实卡在服务层，不是代码问题：
-
rabbitmq-server必须正在运行：Linux 下执行systemctl is-active rabbitmq-server，返回active才算就绪 - 默认用户
guest只允许本地连接（localhost），远程访问会拒绝。生产环境必须创建专用用户：rabbitmqctl add_user myapp password+rabbitmqctl set_permissions -p / myapp ".*" ".*" ".*" - 防火墙要放行
5672端口（AMQP）；若用 Web UI，还需15672 - 连接时指定的 vhost（如
/）必须存在，否则AMQPConnectionException会报 “NOT_FOUND - no vhost”
生产者发消息必须设 delivery_mode => 2
不加这个参数，消息默认是内存存储，RabbitMQ 重启后全丢。尤其在订单、支付、通知等关键场景，等于没做异步——只是把阻塞从 HTTP 进程挪到了队列里。
正确写法示例：
立即学习“PHP免费学习笔记（深入）”；
$message = new AMQPMessage(json_encode($task), [
'delivery_mode' => 2, // 持久化到磁盘
'content_type' => 'application/json',
]);
$channel->basic_publish($message, '', 'order_queue');
-
delivery_mode => 1（非持久）仅适合日志、埋点等可丢失数据 - 队列本身也得声明为持久：
$channel->queue_declare('order_queue', false, true, false, false)—— 第三个参数true表示durable - 交换机（如果用了）同样需要
durable => true，否则路由规则随重启消失
消费者进程不能跑在 Web 请求里
常见错误是把消费者逻辑写进 index.php 或 Laravel 的某个控制器里，每次 HTTP 请求都拉起一次消费循环。这会导致：
- 连接数爆炸（每个请求建一个 TCP 连接）
- 消息重复消费（多个实例同时
basic_consume同一队列） - 超时中断（Web 服务器如 Nginx 默认 60s 超时，消费者还没处理完就被 kill）
正确做法是写成独立 CLI 脚本，用 supervisor 或 systemd 守护：
php /var/www/myapp/worker/email_worker.php
脚本内必须启用手动确认（$msg->ack()），并在处理成功后才调用，否则异常退出会导致消息卡在 unacked 状态，队列积压。
消息体结构建议用数组而非裸字符串
直接传 "send_email:123" 这类字符串，后期加字段、改逻辑非常脆弱。推荐统一用关联数组封装任务元信息：
$task = [
'job' => 'send_welcome_email',
'payload' => ['user_id' => 123, 'template' => 'welcome_v2'],
'attempts' => 0,
'created_at' => time(),
];
- 便于消费者做类型分发：
switch ($task['job']) { case 'send_welcome_email': ... } - 预留重试机制入口：
attempts字段可用于死信前的有限重试 - 避免 JSON 解码失败导致整个消费者崩溃——加个
json_last_error() === JSON_ERROR_NONE判断很必要
RabbitMQ 不是“加个队列就高并发”，消息确认、持久化、消费者守护、错误隔离，缺一不可。最容易被跳过的，是消费者进程的生命周期管理——它不像 Web 请求有天然边界，一旦挂掉，队列就静默堆积，直到监控报警。
