DB::listen() 默认监听带问号占位符的SQL，需手动用 str_replace 逐个替换 $bindings 才得真实SQL；输出不可见因标准输出被丢弃，应写日志或用 dump()；仅捕获 Query Builder 查询，注册须在 AppServiceProvider::boot()；生产环境应禁用以避免性能损耗。
DB::listen() 怎么监听到实际执行的 SQL？
默认情况下 DB::listen() 拿到的是带问号占位符的原始语句，不是最终发给数据库的、带真实参数的 SQL。这不是 bug，是 Laravel 为防止日志泄露敏感数据做的预处理。
- 必须手动拼接
$query和$bindings才能看到“真实执行的 SQL” -
$bindings里的值类型可能和字段不匹配（比如null、bool），直接vsprintf会报错或结果异常 - 推荐用
str_replace逐个替换，更安全：$sql = $query; foreach ($bindings as $binding) { $sql = preg_replace('/\?/', var_export($binding, true), $sql, 1); }
监听器里 print_r(var_dump()) 为什么没输出？
Laravel 的查询监听器运行在请求生命周期中，但标准输出（echo/var_dump）不一定出现在你期望的位置——比如 API 接口返回 JSON 时，这些输出会被丢弃或混入响应体，导致“看不见”。
- 开发环境优先写到日志：
Log::debug('SQL:', ['sql' => $sql]) - 调试页面可用
dump()（Laravel 自带），它会走 Symfony VarDumper，支持 HTML 渲染且不干扰响应 - 不要在监听器里调用
exit或dd()，会中断后续查询甚至整个请求
监听器加了但没触发，常见原因有哪些？
不是所有查询都会进 DB::listen() —— 它只捕获通过 DB facade 或 Query Builder 发起的查询，Eloquent 的部分操作可能绕过它。
-
Model::find()、Model::first()等查主键操作，如果命中了模型缓存（->withCasts()或自定义访问器影响不大，但缓存层可能跳过 DB） - 事务内嵌套查询、读写分离场景下，监听器注册位置不对（比如只在主连接注册，但从连接执行了查询）
- 监听器注册太晚：必须在查询执行前注册，例如放在
AppServiceProvider::boot()，而不是某个中间件或控制器里
性能分析时，怎么避免监听器本身拖慢请求？
监听器每次查询都执行，如果里面做了文件写入、远程调用或复杂字符串处理，很容易成为性能瓶颈，尤其高并发时。
- 生产环境禁用监听器，或用开关控制：
if (app()->environment('local')) { DB::listen(...) } - 避免在监听器里做耗时操作：不调用
file_put_contents，不用sleep()模拟，不发起 HTTP 请求 - 如需长期采集 SQL，改用数据库原生慢日志（MySQL
slow_query_log）或 APM 工具（如 Blackfire、Laravel Telescope）
$time 是 PDO 返回的执行耗时，不含网络延迟、连接建立、结果集解析等环节。想定位完整 SQL 延迟，得结合数据库服务端日志看。 
