Laravel 默认不记录 SQL 日志，关闭本质是移除手动添加的 DB::listen() 监听逻辑；APP_DEBUG=false 会禁用内置查询日志但不影响自定义监听器；sql-xxx.log 是自定义日志行为所致。
默认不记录 SQL 日志，关不关其实取决于你有没有手动开启过。 Laravel 本身不会自动把所有查询写进日志文件，DB::getQueryLog() 返回空数组就是最直接的证据——它压根没开。所谓“关闭”，其实是撤回你之前主动加的监听逻辑或配置项。
DB::listen() 监听器怎么停用
如果你在 AppServiceProvider@boot() 或其他地方用了 DB::listen() 记录 SQL，那它就是唯一活跃的 SQL 日志源头。停用只需删掉或注释掉这行注册代码：
- 找到
app/Providers/AppServiceProvider.php的boot()方法 - 删掉类似
DB::listen(function ($query) { ... });的整段监听逻辑 - 如果监听器被抽成独立类（比如
QueryLogger），还要确认没有在EventServiceProvider里注册对应事件 - 改完后无需清缓存，但建议重启队列或长连接进程（如 Horizon、Swoole），否则旧监听可能还在内存里跑
APP_DEBUG=false 后还会有 SQL 日志吗
不会。虽然 APP_DEBUG=false 主要影响异常页面展示，但它会连带抑制很多调试级行为：包括 DB::getQueryLog() 的底层开关、Debugbar 的 SQL 面板、以及部分 IDE Helper 插件的实时捕获。关键点是：
-
APP_DEBUG=false时，Laravel 内部会跳过初始化查询日志缓冲区，DB::enableQueryLog()也无效 - 但如果你自己写了
DB::listen()并部署在生产环境，它仍会执行——这属于代码逻辑，和APP_DEBUG无关 - 别指望靠关
APP_DEBUG来“关闭 SQL 日志”，真正起作用的是你写的监听器是否存在
storage/logs/ 下出现 sql-xxx.log 是谁写的
不是 Laravel 默认行为，一定是你自己或团队引入的自定义日志逻辑。常见来源有：
- 在
DB::listen()回调里手动调用了Log::channel('sql')->info(...)，且config/logging.php中定义了sqlchannel 指向单独文件 - 用了第三方包（如
laravel-query-detector或自研审计中间件），它们会在storage/logs/下创建专属日志 - 某些部署脚本或运维工具（比如 Laravel Envoy 任务）在部署时注入了日志逻辑
- 检查
config/logging.php里有没有channels.sql配置；再全局搜Log::channel('sql')或storage_path('logs/sql-')
最容易被忽略的是：监听器一旦注册，就始终生效，哪怕只在本地开发环境写过一次，上线时忘了删，它就会默默记满磁盘。真正的“关闭”动作永远落在代码层，而不是配置开关或日志级别调整上。
