app_debug=true仅控制whoops页面渲染，真正显示错误还需php的display_errors=on和error_reporting=e_all配对；否则仍白屏或无堆栈。

APP_DEBUG=true 不能直接“开启调试”，它只控制是否渲染 Whoops 错误页面；真正让错误可见，还得配对 PHP 的 display_errors 和 error_reporting。单独改 APP_DEBUG=true 却看不到报错，八成是这俩没对上。

APP_DEBUG=true 为什么没反应

常见现象：改了 .env 里的 APP_DEBUG=true，刷新页面还是白屏或 500，没堆栈、没 Whoops 页面。

• APP_URL 不匹配当前访问地址 → 导致错误页的 JS/CSS 加载失败，页面空荡荡（尤其用 Nginx 反代时）
• PHP 配置里 display_errors = Off → Laravel 想吐错误也吐不出来，得去 php.ini 或 php -i | grep display_errors 确认
• error_reporting 被设为 0 或太低 → 即使 APP_DEBUG=true，底层错误也不触发捕获链
• 缺少 facade/ignition 包（Laravel 9+ 默认依赖）→ 报错 Whoops\Handler\PrettyPageHandler not found，执行 composer require facade/ignition --dev 补上
• 缓存没清 → 改完 .env 必须跑 php artisan config:clear，否则旧配置还在内存里

APP_DEBUG=false 时怎么定位问题

生产环境关掉 APP_DEBUG 是铁律，但不等于没法查。关键靠日志 + 临时观测手段。

laravel-specialist

精通 Laravel 10+，遵循现代 PHP 实践的 Laravel 专家。擅长优雅语法、Eloquent ORM、队列系统及企业级特性...

下载

• 错误默认写进 storage/logs/laravel.log，用 tail -f storage/logs/laravel.log 实时盯住最新 ERROR 行
• 想看某次请求的变量？别用 dd()，改用 \Log::debug('user info', ['user' => $user])，日志可追溯、不中断流程
• 临时需要交互式排查？php artisan tinker 进去手动调模型、查 DB、试逻辑，比改代码再刷新快得多
• 不想动日志又怕漏上下文？装 spatie/ray，加一行 ray($request->all()) 就能无感输出到独立面板

Debugbar 和 Telescope 怎么选

两者不是替代关系，而是适用阶段不同：Debugbar 是开发期浏览器内嵌面板，Telescope 是带持久化存储的后台监控系统。

• barryvdh/laravel-debugbar：适合本地快速看 SQL、视图、路由、缓存命中率，安装后开箱即用，但仅限 dev 环境，且会拖慢响应（尤其启了 views 或 db 收集器）
• laravel/telescope：适合 staging 或内部测试环境，数据落库、可查历史、支持权限控制，但要额外跑 php artisan telescope:install 和 migrate，且默认只在非 production 环境注册
• 别在生产环境装 Debugbar —— 它会把 SQL 绑定参数、模板路径、中间件顺序全打在 HTML 里，白给攻击者画地图

最常被忽略的是：Laravel 的调试模式和 PHP 的错误机制是两层。你配对了 APP_DEBUG、display_errors、error_reporting，才真正打通从语法错误到页面渲染的完整链路。少一个，就卡在半路。