队列任务读不到.env变量是因为worker进程启动时只加载一次环境变量，修改后必须执行php artisan queue:restart重启进程；config:cache会固化env()值，无法动态更新；不同队列连接无法原生隔离环境变量。
队列任务里读不到 .env 里的变量？因为进程没重载
Laravel 队列任务运行在独立的长期进程（比如 php artisan queue:work）中，启动时只读一次 .env，后续改了环境变量、重启了 Web 服务，队列进程根本不知道。你看到的“变量没生效”，八成是这个原因。
实操建议：
- 每次修改
.env后，必须手动重启队列工作进程：php artisan queue:restart（它发信号让正在运行的 worker 优雅退出，新 worker 会重新加载环境） - 别依赖
php artisan config:clear或config:cache来“刷新”环境变量——它们只影响配置缓存，不触碰$_ENV或getenv()的原始来源 - 如果用 Supervisor 管理队列，记得在
supervisorctl restart前先跑queue:restart，否则新进程可能仍沿用旧 env
想让不同队列连接用不同 .env 变量？Laravel 不支持原生隔离
Laravel 没有“每个 queue connection 绑定独立 .env”的机制。所有队列任务共享同一份 $_ENV，靠 .env 文件本身无法实现 per-queue 环境隔离。
常见错误现象：在 .env 里写 QUEUE_CONNECTION=redis 和 QUEUE_CONNECTION=sqs 并期望它们各自读不同变量——这行不通。
可行路径：
- 用配置文件动态覆盖：在
config/queue.php里按 connection 名条件加载不同配置，比如env('REDIS_HOST_FOR_EMAILS')和env('SQS_REGION_FOR_NOTIFICATIONS')，再在.env中显式定义这些专用键 - 把差异化参数直接传进任务构造函数或
dispatch()，避免从环境变量里猜逻辑分支 - 极端场景下，可为不同队列起不同 supervisor 进程组，并配不同
environment=段（Supervisor 支持），但需确保 Laravel 启动时不覆盖——这容易出兼容问题，PHP 版本和 SAPI 模式都得小心
config:cache 后环境变量失效？因为 env() 被替换成常量值了
执行 php artisan config:cache 时，Laravel 会把所有 config/*.php 中调用 env() 的地方替换成当前值（比如 'host' => env('DB_HOST', '127.0.0.1') 变成 'host' => '127.0.0.1'）。之后哪怕改 .env，队列进程也看不到变化。
所以：
- 生产环境启用了
config:cache，就别指望靠改.env动态切队列行为——它已经固化了 - 如果真需要运行时读环境变量（比如灰度开关），不要在 config 文件里用
env()，改用$_ENV或getenv()直接读，在任务逻辑里判断 - 检查缓存是否启用：
php artisan config:clear后立刻dd(config('database.default'))，看输出是否还是字符串而非env()调用痕迹
为什么不能靠 putenv() 在任务里临时改环境？风险很高
有人试过在 job handle() 里写 putenv('APP_ENV=staging')，以为能临时切换上下文。这很危险：
- PHP 的
putenv()是进程级的，会影响该 worker 进程后续所有任务，不是当前 job 局部有效 - 某些扩展（如 opcache）或底层库（如 cURL）可能缓存了初始 env 状态，中途改了也不生效
- 多线程模型（如 PHP-FPM 的子进程复用）下更不可控，Laravel 队列虽单线程，但 worker 生命周期长，污染持续存在
- 真正需要隔离，应该用不同 queue connection + 显式参数传递，而不是动全局 env
最易被忽略的一点：很多人以为「队列任务是异步的，所以环境肯定独立」，其实它只是异步执行，不是异步加载——环境加载只发生在 worker 启动那一刻。改环境不重启 worker，等于对牛弹琴。
