laravel启用config:cache后.env彻底失效，因启动时直接加载bootstrap/cache/config.php并跳过.env解析，env()函数恒返回null；所有环境变量须在缓存生成前固化至配置文件，运行时仅能通过config()访问。
配置缓存一开，.env 就彻底失效了——这是 Laravel 配置管理里最常被忽略的硬约束。
config:cache 会跳过 .env 加载
运行 php artisan config:cache 后，Laravel 启动时直接加载 bootstrap/cache/config.php，完全绕过 LoadEnvironmentVariables 步骤。这意味着：env() 函数在缓存后永远返回 null（除非你手动在缓存文件里写死值）。
- 开发阶段改了
.env却没生效？八成是缓存没清 - 生产环境必须用
config:cache提升性能，但前提是所有env()调用都已固化为实际值（比如通过部署脚本注入） -
APP_ENV和APP_DEBUG这类关键变量，在缓存后也失去动态性——它们的值被“拍平”进数组，不再响应.env变更
config() 函数读的是缓存后的 Repository 实例
config('database.default') 并不是每次去读文件，而是从 Illuminate\Config\Repository 实例里取值。这个实例在 LoadConfiguration::bootstrap() 中初始化，数据源取决于是否命中缓存：
- 有缓存 →
$items = require bootstrap/cache/config.php - 无缓存 →
$this->loadConfigurationFiles($app, $config)逐个requireconfig/*.php - 无论哪种路径，
config()拿到的都是同一个Repository对象，后续调用全是内存读取
多环境配置文件（如 database.testing.php）只在无缓存时生效
Laravel 支持按 APP_ENV 自动加载 config/database.testing.php 这类文件，但该机制依赖 loadConfigurationFiles() 的扫描逻辑。一旦启用缓存，这个扫描过程被跳过，只有 config.php 里的内容起作用。
- 测试命令
php artisan test读不到.env.testing？先确认没执行过config:cache - 想让测试环境走独立配置，要么禁用缓存，要么在 CI 部署时用
php artisan config:cache --env=testing（Laravel 9+ 支持）生成专用缓存 -
config/database.php里用env('DB_CONNECTION', 'mysql')是安全的；但若写成'connection' => env('DB_CONNECTION') ?: 'mysql'，缓存后?:左侧为null，右侧默认值才生效——容易掩盖配置缺失问题
config:clear 不等于重载 .env
php artisan config:clear 只是删掉 bootstrap/cache/config.php，它不会触发 .env 重读。真正重载 .env 需要重启 PHP 进程（FPM reload / Valet restart / Homestead 重连）或至少让下次请求重新走完整启动流程。
- 修改
.env后，仅运行config:clear不够，Artisan 命令可能仍读旧值（因为命令行进程未重启） - Web 请求通常能立即生效，但前提是 Web 服务器（Nginx/Apache）没有复用旧的 PHP-FPM worker 进程
- 最稳妥做法：改完
.env→config:clear→ 重启 PHP-FPM 或容器
缓存与环境变量的耦合关系是 Laravel 配置体系里最易误判的一环——它不报错，只静默失效。上线前务必确认 config:cache 的生成时机和环境上下文是否匹配。
