PHP 无内置队列，需对接 RabbitMQ、Redis 等外部服务实现异步任务处理；因其同步阻塞模型，耗时操作须移出请求生命周期以提升响应速度与系统稳定性。
PHP 本身没有内置的“队列系统”，所谓“PHP 的队列系统”实际是指 PHP 作为生产者或消费者，对接外部队列服务（如 RabbitMQ、Redis、Beanstalkd 或 Apache Kafka）所构建的异步任务处理机制。它不是语言特性，而是架构选择。
为什么 PHP 需要外接队列？
PHP 是同步阻塞模型，一次请求生命周期内只能顺序执行代码。遇到耗时操作（如发邮件、生成报表、调用第三方 API、处理图片），直接在请求中做会导致响应变慢、超时、用户卡顿，甚至压垮 Web 服务器。
把这类操作“挪出去”，交给独立的、可伸缩的队列服务和工作进程（worker）异步执行，是解耦和提升稳定性的核心手段。
典型应用场景：哪些任务该进队列？
判断标准很简单：只要这个操作不直接影响当前 HTTP 响应内容，且允许“稍后完成”，就适合进队列。
立即学习“PHP免费学习笔记（深入）”；
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
-
发送邮件 / 短信通知：SMTP 延迟高，失败重试逻辑复杂，绝不应在请求中同步调用 -
日志归档 / 行为埋点上报：写入 HDFS 或数据仓库耗时长，不应阻塞主业务流程 -
图片/视频转码、PDF 生成：CPU 密集型，且耗时不可控，必须剥离出 Web 进程 -
缓存预热 / 失效清理：比如商品下架后批量删 Redis key，避免穿透到 DB -
第三方系统回调确认：如支付成功后调用 ERP 接口，失败需重试，不能卡住用户支付结果页
常见实现方式与选型注意点
不是所有队列都适合 PHP 场景。选型要看可靠性、运维成本、PHP 生态支持度：
-
RabbitMQ：功能最全（死信、延迟、优先级队列），有成熟 PHP 客户端（php-amqplib），但部署运维较重，小项目易过度设计 -
Redis（用LPUSH/BRPOP或Stream）：轻量、PHP 原生支持好（ext-redis），适合中小流量、允许少量丢失的场景；Stream支持消费组和 ACK，已接近专业消息队列能力 -
Beanstalkd：极简、专注任务队列（非通用消息队列），PHP 有稳定客户端（pda/pheanstalk），适合纯“后台任务”场景，但生态弱、社区更新慢 -
Kafka：吞吐极高，但 PHP 客户端（如rdkafka）配置复杂，且 Kafka 不保证单条消息严格有序（分区粒度），PHP 应用很少直接对接，多用于日志管道而非业务任务
别迷信“高级队列”。一个用 Redis Stream + supervisord 管理的 php artisan queue:work（Laravel）或自研 worker.php 脚本，足以支撑百万级订单的异步通知。
容易被忽略的关键细节
队列不是加个 push 就完事。真实落地时，这几个点常导致线上事故：
-
任务序列化内容必须轻量：不要传$this、resource、Closure或大数组 —— 反序列化失败或内存溢出很常见 -
worker 进程必须手动重启或平滑 reload：PHP 不自动加载新代码，改了任务逻辑后不重启 worker，永远执行旧版本 -
没有失败重试 + 死信处理：网络抖动、DB 暂不可用等临时错误必须重试（带退避），连续失败的任务要进死信队列人工介入，否则静默丢任务 -
Redis 队列没设过期时间：用LPUSH+BRPOP时，如果 worker 崩溃未及时DEL，任务可能永久滞留（Stream更安全）
队列的价值不在“能异步”，而在于让失败可见、让重试可控、让扩容可测 —— 这些都要靠具体实现里的防御性编码，不是框架自动给的。
