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 是铁律，但不等于没法查。关键靠日志 + 临时观测手段。
- 错误默认写进
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，才真正打通从语法错误到页面渲染的完整链路。少一个，就卡在半路。
