Laravel队列长驻进程导致容器绑定、数据库连接、缓存、任务属性等状态跨任务污染，需通过子容器、显式事务控制、缓存前缀、一次性任务类等手段隔离。
队列任务里改了 $app->bind() 为什么下个任务还生效？
因为 Laravel 队列工作进程（如 php artisan queue:work）默认长驻内存，Container 实例不会在每个任务间重置。你在一个任务里调用 $app->bind('foo', ...)，这个绑定会一直留在容器里，影响后续所有任务——这不是 bug，是设计使然。
常见错误现象：Class foo is not instantiable 突然出现，或某个服务行为异常，只在队列里复现，Web 请求中正常。
- 真正需要隔离的不是「任务逻辑」，而是「服务容器状态」和「全局静态变量」
- 不要在任务中调用
$app->bind()、$app->singleton()或修改config()值 - 如果必须动态绑定，改用「每次任务内新建子容器」：
$childContainer = $app->newChildContainer(); $childContainer->bind(...); - 注意
config(['foo.bar' => 'baz'])是全局生效的，它不随请求/任务生命周期重置
为什么 DB::transaction() 在队列里没回滚？
因为事务作用域绑定的是当前数据库连接实例，而 Laravel 队列进程复用连接，若上一个任务没正确结束事务（比如抛出未捕获异常但没触发 rollback），连接可能处于“挂起事务”状态，下一个任务一执行 DB::transaction() 就直接报错 SQLSTATE[HY000]: General error: 2014 Cannot execute queries while other unbuffered queries are active 或静默失败。
- 永远在
try/catch中显式控制事务，确保DB::rollback()被调用 - 避免在事务中 dispatch 新任务——新任务可能被立刻执行（sync driver）或稍后执行（redis/db driver），但共享同一连接时极易冲突
- 对高并发队列，考虑用
DB::connection('xxx')->beginTransaction()显式指定连接名，避免默认连接被污染 - 测试时用
QUEUE_CONNECTION=sync可复现问题，但别依赖它来掩盖长连接隐患
Cache::forever() 和 Cache::put() 在队列里写缓存为什么变全局了？
缓存驱动本身无“上下文”概念。无论你在 Web 请求还是队列任务里调用 Cache::put('key', $val)，只要用的是同一个缓存后端（比如 Redis），数据就是共享的。所谓“隔离”，从来不是框架自动提供的，而是你设计出来的。
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 队列任务中避免无前缀写缓存，比如改成
Cache::put('job_'.$id.'_result', $data, 3600) - 不要依赖
Cache::forever()存任务中间状态——它不会因任务结束而自动清理，容易堆积 - 如果用文件缓存（
filedriver），注意多个 worker 进程写同一文件可能引发锁竞争或覆盖，生产环境禁用 - Redis 缓存要留意
prefix配置是否一致：不同环境或不同应用共用 Redis 时，CACHE_PREFIX没配好会导致键冲突
任务类里的 protected $user 属性为什么在第二个任务里是上一个用户的？
因为 Laravel 默认把整个任务类序列化进队列，反序列化时会还原属性值；但如果任务类被复用（比如通过 Job::dispatch()->onQueue(...) 多次 dispatch 同一个实例），或者你在 handle() 里手动赋值了静态属性 / 全局变量，就等于在长驻进程中埋了状态炸弹。
- 永远把任务类当成「一次性的 DTO」：构造函数接收原始参数（ID、数组、字符串），不在 handle() 里修改类属性
- 禁止在任务类中使用
static $cache、public $connection等可变状态 - 如果必须预加载关联模型，用
User::find($this->userId)而非在构造函数里查完再赋值给$this->user - 检查是否误用了
implements ShouldQueue, SerializesModels却没加protected $casts，导致 Eloquent 模型序列化后反序列化出错，残留旧实例
最麻烦的不是状态污染本身，而是它往往延迟暴露——可能跑了一周才突然某天某个队列任务读到了三天前另一个用户的 token。这类问题没法靠日志一眼定位，得靠结构约束提前堵死。
