redis的zadd+zrangebyscore是最可控的延迟方案：以时间戳为score、任务为member，配合轮询消费与加锁防重，避免sleep/fork等不可靠方式，兼顾精度、可靠性和低运维成本。
Redis 的 zadd + zrangebyscore 是最可控的延迟方案
PHP 本身没有原生延迟任务调度能力，得靠消息队列或外部存储配合轮询/监听。Redis 的有序集合（ZSet）天然适合做延迟队列：把执行时间戳作为 score，任务内容作为 member，用定时脚本或常驻进程拉取到期任务。
常见错误是直接用 sleep() 或 pcntl_alarm() 做延迟——这会阻塞当前进程，无法并发，且进程崩溃就丢失任务。
- 写入延迟任务：
$redis->zAdd('delay_queue', time() + 300, json_encode(['job' => 'send_email', 'to' => 'user@example.com'])) - 消费端每秒执行一次：
$pending = $redis->zRangeByScore('delay_queue', '-inf', time(), ['limit' => [0, 10]])，再用$redis->zRem('delay_queue', ...)删除已取任务 - 注意：
zRangeByScore返回的是 member 列表，不是键值对；score 需用整型时间戳，别用毫秒（PHPtime()是秒级） - 务必加锁（如
set nx ex）防止多个消费者重复取同一任务
RabbitMQ 的 x-delayed-message 插件需手动启用且不兼容所有版本
原生 RabbitMQ 不支持延迟消息，必须安装 rabbitmq-delayed-message-exchange 插件，并在声明 exchange 时指定类型为 x-delayed-message。很多线上环境因版本老旧或权限限制无法装插件，导致配置失败却报错模糊。
典型报错：NOT_FOUND - no exchange 'delayed_exchange' in vhost '/'，其实是因为插件没启用或 exchange 声明漏了 arguments 参数。
立即学习“PHP免费学习笔记（深入）”；
- 启用插件命令：
rabbitmq-plugins enable rabbitmq_delayed_message_exchange（需重启节点） - PHP 中声明 exchange 必须带：
$channel->exchange_declare('delayed_exchange', 'x-delayed-message', false, true, false, false, false, ['x-delayed-type' => ['S', 'direct']]) - 发送时加 header：
$msg->set('application_headers', new AMQPTable(['x-delay' => 60000]))（单位毫秒） - 该插件在 RabbitMQ 3.8+ 稳定，3.7 及以下可能丢消息，生产环境务必验证
PHP Worker 进程里用 pcntl_fork() 模拟延迟容易失控
有人用 pcntl_fork() 创建子进程，子进程 sleep(300) 后执行任务。问题在于：父进程无法感知子进程是否异常退出；大量 fork 会耗尽系统进程数；sleep() 精度差，且无法取消。
更糟的是，如果子进程里用了 Laravel 的 DB 连接或 Redis 实例，这些资源在 fork 后可能处于脏状态，导致连接超时或数据错乱。
- 避免在 fork 后复用父进程的数据库连接、Redis 实例、文件句柄
- 子进程启动后应立即调用
pcntl_signal_dispatch()并关闭信号继承 - 必须用
pcntl_waitpid()回收子进程，否则变僵尸进程 - 真正需要延迟的场景，优先走 Redis ZSet 或专业队列，而不是自己造 fork 轮子
Laravel Horizon / Supervisor 管理延迟任务时，retry_after 和 timeout 容易配反
用 Laravel 的 dispatch()->delay(now()->addMinutes(5)) 发送延迟任务，底层仍依赖 Redis 的 List 或 ZSet。但 Horizon 的 retry_after（任务最大存活时间）和 timeout（单次执行超时）若设得太短，会导致任务还没到执行时间就被判定为失败并重试。
例如：设了 retry_after=60，但延迟 5 分钟，任务进队列 60 秒后就被 Horizon 当作“卡死”移出队列，永远执行不了。
-
retry_after必须 > 最大延迟时间 + 预估执行耗时（比如延迟 10 分钟，执行最多 2 分钟，则设为 720） -
timeout是单次运行上限，建议略大于业务逻辑平均耗时，但不要超过retry_after - Horizon 的
supervisor配置里，balance模式对延迟任务不友好，建议改用simple模式避免负载误判 - 延迟任务日志要单独归类，否则混在普通队列日志里很难排查“为什么没按时执行”
延迟的精度、可靠性和运维成本三者很难兼顾。ZSet 方案最轻量但要自己写消费者；RabbitMQ 插件功能强但依赖运维配合；框架封装看似简单，参数一配错就静默失效。实际项目里，先跑通 ZSet 基础流程，再根据吞吐和可靠性要求决定是否升级。
