Debugbar 未显示需确认 APP_DEBUG=true 且非 CLI 环境，检查服务提供者是否注册、配置缓存是否清除、是否手动添加 ServiceProvider 并发布配置；消息需在 Messages 面板查看；SQL 收集需调高 limit 和设置 slow_threshold；生产环境严禁启用以防 OOM。
安装后页面没出现 Debugbar，检查服务提供者是否注册
Debugbar 默认只在 APP_DEBUG=true 且非 CLI 环境下启用。常见漏掉的步骤是：Laravel 5.5+ 虽支持包自动发现，但若项目禁用了自动发现（composer.json 中删了 "minimum-stability": "stable" 或手动清除了 vendor/composer/installed.json），Barryvdh\Debugbar\ServiceProvider::class 就不会被自动加载。
解决方法：
- 确认
.env中APP_DEBUG=true且未设置DEBUGBAR_ENABLED=false - 运行
php artisan config:clear清除配置缓存（尤其部署后改过环境变量却没清缓存） - 手动在
config/app.php的providers数组末尾添加：Barryvdh\Debugbar\ServiceProvider::class,
- 再执行
php artisan vendor:publish --provider="Barryvdh\Debugbar\ServiceProvider"发布配置
使用 Debugbar::info() 记录自定义数据但不显示
默认情况下，Debugbar::info()、Debugbar::error() 等方法写入的数据，只有在「Messages」面板中才可见，且该面板默认折叠、不自动展开。很多人误以为没生效，其实是没点开面板。
注意点：
- 确保调用发生在 HTTP 响应生成过程中（不能在
php artisan tinker或队列任务里用——除非你启用了远程日志模式） -
Debugbar::info('user', $user)第二个参数会被序列化显示；若传数组或对象，避免循环引用，否则可能卡住或报Serialization of 'Closure' is not allowed - 如果想让某条消息高亮，用
Debugbar::warning()或Debugbar::error()，它们在面板中带颜色标识
SQL 查询重复出现、慢查询没标红，检查 Query Collector 配置
Debugbar 的 SQL 面板默认只收集前 100 条查询，且不自动标记慢查询（比如 > 100ms），需要手动开启阈值检测。
修改 config/debugbar.php 中相关项：
- 把
'limit' => 100改为更大值（如200），避免高频查询被截断 - 开启慢查询提示：
'slow_threshold' => 100（单位毫秒） - 确认
'collectors' => ['queries' => true]已启用，且数据库连接未被DB::disableQueryLog()关闭 - 注意：Laravel 的
DB::listen()回调与 Debugbar 共享 query log，若你在中间件或监听器里调用了DB::getQueryLog()并清空了日志，Debugbar 就收不到数据
生产环境误启用 Debugbar 导致内存暴涨或 500 错误
Debugbar 在响应结束前会把所有收集的数据（尤其是视图渲染、请求/响应体、异常堆栈）全塞进内存，一旦开启又没限制，大文件上传、大量 Eloquent 关系加载、或 JSON API 返回几百 MB 数据时，直接 OOM。
安全做法：
- 永远不要在生产环境的
.env中设APP_DEBUG=true，这是根本防线 - 即使测试环境也要加白名单控制：
'storage' => ['driver' => 'file']+'enabled' => env('DEBUGBAR_ENABLED', false)，并在.env单独配DEBUGBAR_ENABLED=true - 禁用高开销 collector：
'collectors' => ['views' => false, 'route' => false, 'logs' => false]，保留queries和messages就够调试大部分问题
最常被忽略的是：发布到线上后忘记删掉 debugbar.php 配置里的 'enabled' => true 硬编码，或者用 php artisan serve 本地测试时开着 --env=production 却仍加载了 Debugbar —— 它真会挂掉整个响应。
