Laravel中.env不生效主因是配置缓存未清除，开发时应执行php artisan config:clear；生产环境启用config:cache后.env失效，须改config文件或重生成缓存；.env权限需为600/644；env()不可在config/*.php中直接使用，否则缓存后返回null。
env 文件不生效？先确认 Laravel 是否已清空配置缓存
绝大多数“读不到 .env 值”的问题，其实不是配置写错了，而是 php artisan config:cache 把旧的配置固化了，导致 .env 修改后完全被忽略。
- 开发环境下，**不要长期保留配置缓存**：运行
php artisan config:clear后再试env('APP_NAME') - 如果项目部署在生产环境且用了
config:cache，那.env就彻底失效了——此时必须改config/app.php里对应项，或重新生成缓存 -
.env文件权限需为 600 或 644，不能是 777（尤其在 Linux 上，Laravel 会主动跳过可写权限过高的.env）
env() 函数返回 null？检查变量是否被 config 文件覆盖
Laravel 的 env() 是个“只读取原始 .env 的快捷函数”，但它**不能在 config/*.php 文件里安全使用**——因为这些文件会被缓存，而缓存时 .env 已不可读。
- 在
config/database.php中直接写'host' => env('DB_HOST')看似没问题，但一旦执行过config:cache，这个值就变成null（因为缓存时.env未加载） - 正确做法：所有
env()调用**只出现在config/app.php顶层，或bootstrap/app.php中**；其余 config 文件应通过config('database.host')间接取值 - 调试技巧：在路由闭包里临时加
dd(env('DB_HOST'))，确认基础读取是否正常
APP_ENV=local 但 APP_DEBUG=false？环境判断逻辑比你想的更严格
APP_ENV 和 APP_DEBUG 不是独立开关，Laravel 内部用 app()->environment() 判断环境，而它依赖的是 APP_ENV 值 + 当前配置缓存状态。
-
APP_ENV=local时，app()->environment('local')返回 true；但若配置已缓存，且缓存生成时APP_ENV是production，那即使现在改了.env，结果仍是 false -
APP_DEBUG只控制异常页面显示，不影响日志级别或环境判定——别指望设成 false 就能“假装是生产环境” - 验证当前真实环境：在 Blade 模板里写
{{ app()->environment() }}，比看.env更可靠
多环境部署时，.env 文件怎么安全替换？
本地开发用 .env，线上用 .env.production？Laravel 默认不支持多 env 文件切换，硬改名字或写脚本替换容易出错。
- 推荐方案：**线上不依赖
.env**，把敏感变量直接设为服务器环境变量（如 Nginx 的fastcgi_param，或 systemd 的Environment=），Laravel 会优先读取系统级环境变量 - 如果必须用文件，可用
cp .env.production .env && php artisan config:clear，但务必确保.env不被 Git 跟踪（检查.gitignore是否含.env） - 注意
.env.example只是模板，它不会被自动加载，也别把它当成备份——改了它对运行毫无影响
真正麻烦的从来不是怎么写 .env，而是缓存、加载时机、和服务器环境变量的优先级混在一起时，你根本不知道此刻读到的到底是哪一层的值。
