thinkphp本身不提供php级慢日志，db::listen()仅捕获成功执行sql的耗时；php-fpm慢日志需在www段配置slowlog、request_slowlog_timeout并重启进程才生效，否则日志为空。
ThinkPHP 本身不提供“慢日志”这个独立功能，Db::listen() 捕获的是每条成功执行 SQL 的耗时，不是 PHP 请求级的慢日志；真正的 PHP 级慢日志由 PHP-FPM 提供，必须在 FPM 配置中开启并重启进程，否则 tail -f /www/wwwlogs/php_slow.log 永远为空。
Db::listen() 怎么注册才不会漏掉早期 SQL
监听器必须在数据库连接初始化后、首次查询前注册，否则框架启动过程中自动执行的初始化 SQL（比如读取配置表、检查迁移状态）将不会被捕获。
- 正确位置：在
app/bootstrap.php或自定义服务提供者的register()方法里调用Db::listen()，不要放在控制器、中间件或路由闭包中 - 回调函数接收四个参数：
$sql（原始语句）、$time（毫秒，float）、$explain（EXPLAIN 结果数组，需开启配置）、$master（bool，标识主库查询） - 阈值别硬编码：从配置读取，例如
config('database.slow_sql_threshold', 500)，便于不同环境切换 - 注意：该事件只触发「执行成功」的 SQL；超时、语法错误、连接失败等异常不会进入此回调
为什么事务里 Db::listen() 只触发一次
事务内多条 SQL 在 PDO 默认配置下（PDO::ATTR_EMULATE_PREPARES = false）会被底层合并为单次事件上报，不是 Bug，是驱动对批次执行的优化表现。
- 开发/测试环境可临时关闭预处理模拟：
'options' => [PDO::ATTR_EMULATE_PREPARES => true]，让每条语句单独触发 - 生产环境更推荐手动时间戳方案：事务开始前记录
microtime(true)，commit()或rollback()后遍历Db::getLog()获取所有语句及对应时间戳 - 根本解法是减少事务内非必要查询——比监听更能避免慢 SQL
PHP-FPM 慢日志怎么配才真正生效
宝塔面板里点【保存】只是写入配置文件，不重启 PHP-FPM 进程，slowlog 永远不会写入。必须点击【重启】（不是【重载配置】），且确认进程启动时间已更新。
- 关键配置项必须出现在
[www]段内（如/www/server/php/82/etc/php-fpm.d/www.conf），不能写在全局或注释行里： -
slowlog = /www/wwwlogs/php_slow.log（路径需存在，且www用户有写权限） -
request_slowlog_timeout = 5s（生产建议 3s–5s；设 1s 易被后台 AJAX 误触发） -
catch_workers_output = yes（必须开启，否则error_log()、未捕获异常不会进慢日志） - 验证方式：新建
slow_test.php写<?php sleep(6); ?>，访问后执行tail -n 10 /www/wwwlogs/php_slow.log，看到含script_filename、duration和底部[0x...]函数名才算成功
写慢 SQL 日志最容易卡住主线程的坑
直接用 file_put_contents(..., FILE_APPEND) 同步写日志，在高并发下会阻塞整个请求，甚至拖垮应用。ThinkPHP 默认日志通道虽有缓冲，但不区分慢 SQL 级别，导致慢日志和 debug 日志混在一起，检索困难。
- 必须使用独立异步通道：例如基于
monolog的AsyncStreamHandler，或通过消息队列（如 Redis List + worker）转储 - 日志内容至少包含：
$sql、$time、当前请求 URL（$_SERVER['REQUEST_URI']）、调用栈（debug_backtrace(false, 5)） - EXPLAIN 分析要按条件触发：仅当
$time > config('database.explain_threshold', 1000)且非生产环境才执行，避免额外开销 - 生产环境优先用 MySQL 原生慢日志（
slow_query_log），它不经过 PHP 层，更稳定、更轻量
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
