dispatch()后任务未执行是因为Laravel队列默认不自动运行，需手动启动queue:work进程，且QUEUE_CONNECTION须设为redis或database而非sync。
为什么 dispatch() 后任务没执行？
不是代码没写对，而是 Laravel 队列默认不自动运行——它只是把任务塞进队列存储（Redis/Database），等着你手动启动消费者进程。常见现象是调用 dispatch() 没报错、日志里也看不到失败，但邮件没发、文件没生成、第三方 API 没调用。
- 检查
QUEUE_CONNECTION环境变量是否设为sync（开发时默认值）：这是同步模式，会立刻执行，但**不是异步**；要真异步，得改成redis或database - 确认已运行
php artisan queue:work（单次）或php artisan queue:listen（旧版，不推荐），且该进程没被意外终止（比如终端关闭、Supervisor 未配置） - 如果用
database驱动，确保jobs表存在并可写；用redis则需phpredis扩展启用，且 Redis 连接正常
queue:work 和 queue:listen 到底用哪个？
queue:listen 已废弃（Laravel 5.7+ 起移除），现在只用 queue:work。但它有关键行为差异：默认情况下，queue:work 启动后会复用同一个 Laravel 应用实例处理所有任务，导致内存泄漏、配置未刷新、数据库连接超时等问题。
- 加
--once参数让它每处理一个任务就退出：适合调试或低频任务，但频繁启停开销大 - 生产环境必须配
--max-jobs=100或--max-time=3600，强制进程定期重启，避免内存累积 - 务必配合 Supervisor 管理进程，不能裸跑
queue:work；否则崩溃后无人拉起
任务类里该不该在 handle() 里写 DB 查询？
可以写，但要注意模型状态和连接生命周期。队列任务是“延迟执行的闭包”，它序列化时只存参数，不存整个对象实例。所以你在 dispatch 时传的是 ID，不是 Eloquent 模型本身。
- 错误写法：
$user = $this->user;（假设$this->user是模型实例）→ 反序列化失败或数据过期 - 正确写法：在
handle()里用 ID 查库，如$user = User::find($this->userId); - 如果任务需要大量关联数据，考虑在 dispatch 前预取关键字段（如 JSON 字符串），避免 handle 中 N+1 查询
- 注意事务：队列任务不在原请求事务内，
DB::transaction不会跨进程生效
Redis 驱动下任务重复执行怎么防？
Redis 本身不保证“恰好一次”，网络分区或 worker 崩溃未及时 ack，会导致任务被重新入队。Laravel 默认重试 3 次（$tries = 3），但业务上仍可能出问题。
- 给任务类加
public $uniqueFor = 3600;（秒），配合uniqueId()方法，防止相同参数任务短时间重复入队 - 关键操作加幂等判断：比如发短信前查
sms_logs表是否已有同 order_id 记录 - 不要依赖
failed()方法做补偿逻辑——它只在重试耗尽后触发，中间失败不会进这里 - Redis 的
blocking pop特性让queue:work在无任务时休眠，别误以为卡死
队列不是开关一开就自动变快的魔法，它把“执行时机”从请求周期里剥离开，但同时也把错误排查从单次 HTTP 生命周期，拉长到了后台进程 + 存储 + 网络的链路里。最常被忽略的，是忘记给 queue:work 加内存/时间限制，以及把模型实例直接塞进构造函数。
