Laravel队列worker启动后配置固化在内存中，运行时修改环境变量无效，必须重启worker（如queue:restart）或通过dispatch传参传递动态配置。
队列任务里 config() 读不到运行时修改的环境变量
因为 Laravel 队列 worker 启动后会把配置「固化」进内存，后续 .env 变更或运行时调用 putenv()、$_ENV 修改，对已启动的 worker 进程完全无效。这不是 bug，是设计使然——worker 进程长驻，不 reload 就不会重新解析 .env。
常见错误现象：config('app.name') 在 Web 请求里返回新值，但同个配置在队列任务里始终是旧值；或者用 Artisan::call('config:clear') 也无效，因为那是清当前进程的缓存，不是通知其他 worker。
- 真正生效的方式只有重启队列 worker：
php artisan queue:restart（触发优雅退出）+ 确保 supervisor 或 systemd 自动拉起新进程 - 不要在任务里写
Dotenv\Dotenv::createUnsafeImmutable(__DIR__)->load()—— 多进程下可能污染全局$_ENV，且无法解决配置类（如CacheManager）已初始化的问题 - 如果必须动态加载，把变量从外部传入任务构造函数或
dispatch()参数中，而不是依赖全局 config
Laravel 队列任务如何安全传递运行时配置值
最稳妥的做法是「把需要的值当参数传进去」，绕过 config 加载时机问题。尤其适合多租户、按客户定制行为、A/B 测试等场景。
使用场景：比如发邮件任务需根据用户所属区域选择不同 SMTP 配置，但这些配置存在数据库或外部 API，不能写死在 .env。
- 在 dispatch 时显式传参：
SendNotification::dispatch($user, ['smtp_host' => $host, 'from_email' => $email]) - 任务类中直接用属性接收，不查
config()：public function __construct(public User $user, public array $config) {} - 避免序列化闭包或 Laravel 容器实例（如
app()），会导致反序列化失败或内存泄漏 - 敏感字段（如 API key）若必须传，先加密再传，任务内解密，别裸奔
queue:work 进程是否读取每次任务执行前的 .env
不读。worker 进程启动时只加载一次 .env 到 $_ENV 和 config/ 数组，之后所有任务共享同一份内存配置。哪怕你在任务里手动 file_put_contents('.env', ...)，也不会触发重载。
性能影响很明确：跳过重复加载提升吞吐，但代价是灵活性归零。这也是为什么官方文档强调「修改 .env 后必须重启队列服务」。
-
php artisan queue:listen也不行——它只是轮询检查新任务，底层仍是长进程 - 某些人用
exec('php artisan config:cache')在任务里执行，这会生成新缓存文件，但当前 worker 仍用旧内存配置，白干 - 唯一能「热更新」的路径是改代码逻辑，让任务自己去查数据库/API，而不是依赖 config
为什么不能在任务里调用 App::environment() 判断环境
这个方法返回的是 worker 启动时的环境（通常是 production），不是当前请求上下文的环境。队列任务没有「请求环境」概念，它脱离 HTTP 生命周期而存在。
容易踩的坑：用 App::environment('local') 来决定是否发 Slack 通知，结果线上 worker 永远不发——因为它是以 production 启动的，哪怕你本地 APP_ENV=local，只要没重启 worker，它就永远不知道。
- 判断逻辑应前置：Web 请求里根据环境决定是否 dispatch 某个通知任务，而不是在任务里判断
- 如果必须区分，把环境标识作为参数传入：
NotifyAdmin::dispatch('production') -
App::environment()在队列任务里基本等于常量，别把它当动态开关用
Laravel 队列的配置隔离性比想象中更强，很多「理所当然」的运行时行为其实被进程生命周期锁死了。真要动态，就得接受「传参」或「查外部」这两条路，别在 config 加载上反复横跳。
