delay()只接受整数秒，传datetime对象会转为0导致立即执行；正确做法是diffinseconds()计算秒数；redis队列需确保retry_after大于最大延迟且小于key过期时间；绝对时间执行需自建scheduled_jobs表+定时任务扫描。
delay() 方法只能接受秒数，不能传时间戳或 DateTime 对象
很多人想直接 dispatch((new SendEmailJob())->delay(now()->addHours(2)))，结果报错或立刻执行——因为 delay() 底层只认整数秒，不解析 DateTimeInterface。Laravel 会把对象转成字符串再强转为 int，结果是 0。
正确做法是手动算出秒数：
- 用
now()->addMinutes(30)->diffInSeconds()（推荐，语义清晰） - 或直接
30 * 60，但硬编码难维护 - 别用
strtotime()或time() + 3600，时区易出错
Redis 队列下 delay() 依赖 `retry_after` 配置
如果你用 Redis 作队列驱动，delay() 实际靠 Redis 的 ZSET 排序 + Laravel 消费者轮询实现。但若任务在延迟期间被消费进程重启，或 retry_after 设置过短（比如 5 秒），任务可能被误标为“失败”并重入队列，导致提前执行。
检查你的 config/queue.php 中 Redis 连接的 retry_after 值：
- 必须大于最大预期延迟时间（例如最长延迟 24 小时 → 设为
86400） - 同时要小于 Redis key 过期时间（默认
retry_after + 60），否则 key 被删，任务丢失 - 别设成
0，Laravel 不支持
指定绝对时间点执行？得自己封装调度逻辑
Laravel 没有原生的 runAt($datetime) 方法。如果需求是“明天上午 9:00 整点发短信”，靠 delay() 算秒数容易因部署时间偏差、时区切换出错。
更稳的做法是：用 Laravel 的 Schedule 每分钟扫一次数据库，查出该分钟内应触发的任务，再 dispatch：
- 建一张
scheduled_jobs表，存job_class、payload、run_at（datetime） - 在
App\Console\Kernel::schedule()里加$schedule->command('jobs:dispatch-pending')->everyMinute() - 命令中查
where('run_at', '，dispatch 后删记录
这比死磕 delay() 更可控，也避免 Redis ZSET 在大延迟下的精度衰减问题。
Supervisor 日志里看不到延迟任务？它根本没进队列
常见错觉：加了 ->delay(3600)，但 Supervisor 日志没打印新任务，以为“没生效”。其实延迟任务提交后立即返回，不会阻塞；它只是被写进 Redis 的 queues:default:delayed ZSET，还没到执行时间就不会出现在 ready 队列里。
验证是否成功入延迟队列：
- 用
redis-cli连上 Redis，执行zrange queues:default:delayed 0 -1 WITHSCORES - 看到类似
"{\"job\":\"...\"}" 1717023600就说明 OK - 如果为空，检查是否用了
sync驱动（开发环境默认），它不支持延迟
真正容易被忽略的是：延迟任务的「首次可见时间」取决于消费者轮询间隔，默认 1 秒 —— 但实际执行时间可能浮动 ±1 秒，别拿它做精确到毫秒的定时。
