PHP 8.4 不支持 ext-redis 原生队列语义，需用 lPush/brPop 手动实现 FIFO 队列，或选用 symfony/messenger 等成熟组件；注意 JSON 编码、超时设置、死信处理及 Redis 内存与幂等控制。
PHP 8.4 中不能直接用 ext-redis 原生支持队列语义
PHP 本身没有内置队列任务调度能力，ext-redis（哪怕在 PHP 8.4）也只是提供 Redis 协议的客户端封装，不带 enqueue、dequeue 等高级队列抽象。所谓“Redis 队列”，本质是用 LPUSH/RPOP 或 BRPOP 等原子命令模拟 FIFO 行为，需自行设计结构和容错逻辑。
用 Redis::lPush() 和 Redis::brPop() 实现基础任务入队与阻塞消费
这是最轻量、兼容性最好（PHP 7.4+ / 8.4 均可用）的方式，适合低并发、无严格可靠性要求的场景。注意：PHP 8.4 默认启用严格类型检查，调用前确保连接已初始化且未关闭。
-
lPush()入队：任务数据建议 JSON 编码，避免二进制或特殊字符破坏结构 -
brPop()出队：必须设超时（如0表示永久阻塞，5表示 5 秒），否则会立即返回null导致忙轮询 - 消费失败时，别直接丢弃——应记录日志并考虑重推回队列或转入死信列表（如
LPUSH queue:dlq ...）
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
// 入队：发送一个简单任务
$job = json_encode(['type' => 'send_email', 'to' => 'user@example.com']);
$redis->lPush('queue:jobs', $job);
// 消费：阻塞等待最多 5 秒
$result = $redis->brPop(['queue:jobs'], 5);
if ($result && count($result) === 2) {
$payload = json_decode($result[1], true);
// 执行任务逻辑...
}
PHP 8.4 下推荐用 php-enqueue 或 symfony/messenger 替代手写
手动实现易出错：缺乏重试策略、任务超时控制、并发竞争处理、监控埋点等。PHP 8.4 对协程（ext-uv）、FFI 支持增强，但主流队列库尚未全面适配其新特性；此时更稳妥的选择是成熟组件：
-
symfony/messengerv7+ 已声明支持 PHP 8.4，可通过RedisTransport直接对接 Redis，自动处理序列化、ACK、重试、延迟队列 -
php-enqueue（已归档）仍有项目在用，但新项目不建议；其redis包依赖旧版predis/predis，与 PHP 8.4 的 strict type 要求偶有冲突 - 若用
ext-redis，需确认Redis::setOption(Redis::OPT_SERIALIZER, Redis::SERIALIZER_PHP)未被启用——它会导致 JSON 数据被二次序列化，消费端解码失败
容易被忽略的 Redis 队列边界问题
很多人只关注“能跑”，却在压测或上线后遇到诡异故障：
立即学习“PHP免费学习笔记（深入）”；
- Redis 内存爆满：未设置
maxmemory和淘汰策略（如allkeys-lru），导致LPUSH失败却不报错（返回0） - 消费者崩溃导致任务丢失：没用
BRPOP+LREM组合实现可靠出队，而是RPOP后再处理——中间 crash 就永远丢失 - 多实例消费同一队列时出现重复执行：Redis 无内建锁机制，需靠
SET job:123 lock EX 30 NX这类方式做幂等控制，不能只靠队列名隔离
真正稳定的队列不是“写完就能用”，而是得覆盖失败重试、进度追踪、积压告警这些环节——PHP 8.4 只是运行环境，不是队列解决方案。
