最直接方法是使用DB::enableQueryLog()和DB::getQueryLog()，但仅对当前请求有效且需在查询前启用；DB::listen()需在AppServiceProvider::boot()中注册并确保APP_DEBUG=true；可结合debug_backtrace()添加上下文定位，Telescope适用于local环境但有性能和噪音问题。
怎么在 Laravel 开发环境实时看到 SQL 执行语句
开发时想确认某段代码到底发了什么 SQL，最直接的办法是开启查询日志并手动触发打印——DB::enableQueryLog() 和 DB::getQueryLog() 配合用就行，但要注意它只对当前请求有效，且默认关闭。
- 必须在查询前调用
DB::enableQueryLog()，否则日志为空 - 执行完要查的数据库操作后，立刻用
DB::getQueryLog()获取数组，里面每个元素是带query、bindings、time的关联数组 - 如果用了 Query Builder 或 Eloquent，它们都走底层
DB，所以能捕获；但原生 PDO 操作或直连不经过DB类的，不会记录 - 别在生产环境开这个，性能损耗明显，且可能泄露敏感参数（
bindings是原始值，没脱敏）
为什么 DB::listen() 没反应？常见配置漏项
DB::listen() 是事件监听方式，比手动启停日志更灵活，但它依赖 Laravel 的事件系统正常工作——很多人加了回调却看不到输出，基本是因为没注册到正确时机或环境不对。
- 监听必须在服务提供者（如
AppServiceProvider::boot()）里注册，不能写在控制器或中间件里，否则可能错过连接初始化 - 确保
APP_DEBUG=true，Laravel 在非调试模式下会跳过部分日志逻辑 - 回调函数里别只
dump()，CLI 请求看不到，建议写文件：file_put_contents(storage_path('logs/sql.log'), print_r($query, true), FILE_APPEND) - 注意闭包变量作用域：如果在监听里用了
$this或外部变量，得用use显式传入，不然报错或取不到值
如何让 SQL 日志带上下文（比如哪个控制器、哪行代码触发）
光看 SQL 不知道来源，调试效率低。Laravel 本身不自带堆栈追踪，但可以用 debug_backtrace() 快速补上关键信息。
- 在
DB::listen()回调里加一行：$backtrace = debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 3)，取前三帧就够定位到业务层 - 重点关注
$backtrace[1]['file']和$backtrace[1]['line']，通常是调用get()或first()的地方 - 别用
debug_backtrace()记录高频查询（比如列表页分页），堆栈生成开销大，容易拖慢响应 - 如果用 Horizon 或队列，记得在队列任务里单独加监听——主应用的
boot()不会自动生效到子进程
Laravel Telescope 能替代手写监听吗？适用边界在哪
Telescope 是官方扩展，能图形化展示 SQL，但它不是“开关一开就全有”的银弹，尤其在非本地环境或轻量项目里反而增加负担。
- Telescope 默认只在
local环境启用，改TELESCOPE_ENABLED环境变量才能在staging用，但要注意它会存大量数据到数据库，表可能涨得很快 - 它记录的是完整请求生命周期内的所有 SQL，包括框架内部查询（如 session、config 加载），噪音多；而手写
DB::listen()可以加条件过滤，比如只抓select或某个表名 - 如果项目没装 Redis 或不想多一个后台入口，Telescope 的价值就打折扣；这时候一行
DB::listen()+ 文件写入更轻量、更可控 - Telescope 的 SQL 面板里点开能看到绑定参数，但不会自动展开堆栈，仍需配合日志或断点
真正麻烦的不是怎么看到 SQL，而是当多个 trait、scope、accessor 嵌套调用时，SQL 怎么和业务逻辑逐行对齐——这时候得靠带位置信息的日志，而不是依赖工具自动猜。
