线上环境必须设为app_debug=false，因开启该模式会暴露异常堆栈、环境变量、配置及源码上下文，引发cve-2021-3129等rce漏洞，并直接泄露db_password、api_key等敏感信息，且系统环境变量可能覆盖.env设置，需通过config('app.debug')、错误页响应及config:cache文件多层验证是否真正关闭。
不能开，线上环境必须设为 APP_DEBUG=false —— 这不是建议，是安全底线。
为什么 APP_DEBUG=true 在生产环境等于主动开门放攻击者进来
核心风险不是“日志多”或“报错丑”，而是 Laravel Debug 模式会暴露完整异常堆栈、环境变量、已加载配置、甚至部分源码上下文。CVE-2021-3129 就是典型：只要 APP_DEBUG=true 且使用了某些序列化组件（如 monolog + phpunit 依赖残留），攻击者就能通过反序列化链直接触发远程代码执行（RCE），全程无需登录。
- 哪怕你没装
laravel-debugbar，Laravel 自带的异常处理器在APP_DEBUG=true下仍会渲染详细错误页 - 错误页里可能泄露
DB_PASSWORD、API_KEY、APP_KEY等敏感值（尤其当配置写法不规范时） - 某些中间件或服务提供者在 debug 模式下会启用额外调试钩子，扩大攻击面
常见误操作：以为“只临时开一下”就没事
真实运维中，这类“临时”往往变成永久：
- CI/CD 流水线里用
.env.testing覆盖生产环境变量，却漏掉了APP_DEBUG字段 - 手动改
.env排查问题后忘记还原，且未执行php artisan config:clear，导致旧配置缓存仍在生效 - 容器部署时用
docker run -e APP_DEBUG=true覆盖，但镜像构建阶段已固化了 debug 模式逻辑 - 云平台（如 Forge、Envoyer）回滚到含 debug 配置的旧版本，无人复核
怎么确认线上真关了 APP_DEBUG
不能只看 .env 文件 —— 环境变量优先级高于文件，系统级变量可能覆盖它：
- 执行
php artisan tinker，输入config('app.debug')，返回必须是false - 检查是否被系统变量劫持：
echo $APP_DEBUG（Linux）或Get-ChildItem Env:APP_DEBUG（Windows PowerShell） - 访问任意一个 404 或 500 页面，确认返回的是简洁的“Sorry, the page you are looking for could not be found.”，而非带堆栈和变量的 Laravel 错误页
- 运行
php artisan config:cache后，bootstrap/cache/config.php中'debug' => false必须硬编码存在（避免运行时再读 .env）
最危险的盲区是：你以为关了，其实某个配置层悄悄绕过了它。比如用了 DEBUGBAR_ENABLED=true 却没关 APP_DEBUG，Debugbar 的服务提供者虽会降级，但底层异常处理器仍处于 debug 模式 —— 它不看你 Debugbar，只认 config('app.debug')。
