修改 .env 后不生效是因为配置被缓存；开发环境需清 config 缓存，生产环境须重新 config:cache；应通过 config() 读取映射到配置文件的变量，而非直接调用 env()。
修改 .env 文件后不生效？先确认 Laravel 是否读取了它
Laravel 启动时会用 vlucas/phpdotenv 加载 .env，但只在应用初始化阶段加载一次。如果你改完 .env 就直接刷新页面，大概率看不到变化——因为配置已被缓存。
常见错误现象：APP_NAME 改了但 php artisan tinker 里 env('APP_NAME') 还是旧值；或者 config:cache 后死活不认新变量。
- 开发环境：删掉
bootstrap/cache/config.php（如果存在），再运行php artisan config:clear - 生产环境：不能靠清缓存“救”，必须重新运行
php artisan config:cache（且确保.env已就位） - 验证是否生效：在路由或控制器里临时加一行
dd(env('APP_NAME'))，别只看视图或 config 文件里的引用
env() 函数只能在配置文件里用？不是的，但有严格限制
env() 是 phpdotenv 提供的辅助函数，Laravel 官方明确不建议在业务代码中直接调用它——因为一旦你执行过 config:cache，env() 就永远返回 null（缓存后的配置不再读取 .env）。
正确做法是把环境变量映射进配置文件，再通过 config() 读取：
- 在
config/app.php里写：'name' => env('APP_NAME', 'Laravel') - 然后 anywhere 都能安全用
config('app.name')，它不受缓存影响 - 不要在模型、服务类、中间件里写
env('DB_HOST')，尤其上线后必挂
部署时 .env 被 Git 忽略，怎么安全传到服务器？
.env 默认在 .gitignore 里，这是对的——密码、密钥绝不能进仓库。但这也带来实操麻烦：每次部署都要手动传一份，还容易传错环境（比如把本地 .env 传到生产机）。
推荐做法是分层管理：
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 本地开发：用
.env，配合.env.example做模板（只留键名和注释，不填敏感值） - CI/CD 或服务器部署：用环境变量注入，比如 Docker 的
-e DB_PASSWORD=xxx，或 systemd 的Environment=APP_ENV=production - 如果必须用文件：让部署脚本从保密存储（如 HashiCorp Vault、AWS SSM Parameter Store）拉取内容，生成
.env，并设权限为600
别用 scp .env production:/var/www/.env 手动覆盖——漏传、覆盖错机器、权限开太大，都是线上事故高发点。
为什么 APP_DEBUG=true 在生产环境设成 false 还报错？
这往往不是 .env 没生效，而是 APP_ENV 没设对。Laravel 的调试开关逻辑是：只有 APP_ENV=local 且 APP_DEBUG=true 时，才显示详细错误页；否则一律走 APP_DEBUG=false 的静默模式。
典型翻车场景：
- 生产服务器上
.env写着APP_ENV=production，但APP_DEBUG=true—— 错！此时 debug 不起作用，但更危险的是，你以为开了 debug 实际没开 - 服务器 PHP 配置里
display_errors=On，导致底层 PHP 错误仍打屏，掩盖了 Laravel 的配置问题 - 某些托管平台（如 Forge、Envoyer）会覆盖
APP_ENV，得去面板里单独关 debug
最稳的检查方式：在入口 public/index.php 顶部加 die($_ENV['APP_ENV'] ?? 'not set');，亲眼看到值再说。
