Laravel通过先加载.env.{APP_ENV}再fallback到.env实现多环境配置，需系统级设置APP_ENV变量，配置缓存前须确保APP_ENV已生效，敏感值需加引号，避免在config文件中写动态逻辑。
怎么让 .env 文件不进 Git，又能让不同环境自动加载对应配置
靠 Git 忽略 .env 是基础操作，但真正卡住人的是：本地开发用 APP_ENV=local，测试服要 APP_ENV=staging，线上却是 APP_ENV=production，而 Laravel 默认只认 .env 这一个文件，不会自动按环境切。
解决办法是利用 Laravel 的「环境文件加载机制」：它会先尝试读 .env.{APP_ENV}，找不到才 fallback 到 .env。所以你只要在部署时确保服务器上有 .env.staging 或 .env.production，并设好 APP_ENV 环境变量，Laravel 就自动加载对应文件。
-
APP_ENV必须通过系统级环境变量设置（如 Nginx 的fastcgi_param APP_ENV staging，或 systemd 服务的Environment=APP_ENV=staging），不能只写在.env里——因为读.env前就得知道该读哪个.env.xxx -
.env.{APP_ENV}文件里可以只写差异项（比如数据库密码、API 密钥），其余继承自.env；但如果用了.env.staging，.env就完全不加载了，它不是“基线”，而是 fallback - 别把
.env.production提交到仓库——它应该由运维或 CI/CD 在部署时生成或注入，比如用 Ansible 模板、GitHub Actions secrets 注入
Laravel 的 config:cache 为什么在多环境下发疯
缓存配置后，APP_ENV 变量就固化在 bootstrap/cache/config.php 里了。哪怕你改了系统级 APP_ENV，Laravel 也照用旧缓存，导致配置错乱——比如线上跑了 APP_DEBUG=true 却死活关不掉。
根本原因是：config:cache 是在当前环境变量下执行的，它把当时读到的所有配置（包括 env() 调用结果）直接写成 PHP 数组，后续不再查 .env。
- CI/CD 中执行
php artisan config:cache前，必须确保APP_ENV已设为目标环境值（例如APP_ENV=production php artisan config:cache） - 上线部署脚本里，
config:cache和route:cache这类命令得放在环境变量设置之后、应用启动之前 - 如果用容器部署（Docker），别在 Dockerfile 里跑
config:cache——镜像构建时还不知道运行时环境，应该放到entrypoint.sh里，用$APP_ENV动态决定是否缓存、缓存哪套
数据库配置在 config/database.php 里硬编码 env() 有啥隐患
看起来没问题：'host' => env('DB_HOST', '127.0.0.1')，但一旦开了配置缓存，所有 env() 都被求值并固化。问题在于：有些环境变量（比如 DB_PASSWORD）可能含特殊字符（$、:、空格），而 .env 解析器对它们处理不一致，尤其在 shell 层面传入时容易被截断或转义。
更隐蔽的问题是：Laravel 的 env() 函数在缓存开启后不再调用，但如果你在 config/database.php 里写了条件逻辑（比如根据 APP_ENV 切换连接池大小），这部分 PHP 代码在缓存后就失效了——因为缓存存的是最终值，不是逻辑。
- 敏感值（密码、密钥）务必用引号包裹在
.env里：DB_PASSWORD="my$ecr#t p@ss"，否则$ecr可能被 shell 当作变量展开 - 避免在配置文件里写复杂逻辑，比如
if (app()->environment('production')) { ... }—— 缓存后这行永远返回 false 或 true，取决于缓存生成时的环境 - 真要动态配置，用
config()在服务提供者中覆盖，而不是在config/*.php里写分支
如何验证当前 Laravel 加载的是哪个 .env 文件
没有现成命令直接告诉你“我读了 .env.production”，但可以快速定位：Laravel 启动时会在 Illuminate/Foundation/Bootstrap/LoadEnvironmentVariables.php 里按顺序尝试加载 .env.{APP_ENV} → .env，只要第一个存在就停。
最稳的验证方式是临时加一行日志，或者用 Artisan 命令看实际值：
php artisan tinker --execute="echo $_ENV['APP_ENV'] ?? 'not set';"
但这只能看到 APP_ENV 值，看不到文件路径。真正要确认加载源，得在部署后立刻检查：
- 运行
ls -l .env*，看哪些文件真实存在 - 执行
php -r "print_r($_SERVER['APP_ENV'] ?? getenv('APP_ENV'));"，确认系统级变量是否生效 - 如果用了 Apache，注意
SetEnv指令在虚拟主机和目录级作用域不同，有时会被覆盖；Nginx 则必须用fastcgi_param透传，且不能写在location ~ \.php$外层
环境变量和配置文件的加载时机差几毫秒，但足以让整个部署链路出错——多数问题不是配置写错了，而是你以为它被读了，其实根本没走到那一步。
