PHP-FPM 慢日志默认未启用，需在 pool 配置（如 www.conf）中设置非零 request_slowlog_timeout 和有效 slowlog 路径，并重启 PHP-FPM 生效。
PHP-FPM 慢日志是否已启用？先确认配置项
宝塔面板默认不开启 PHP-FPM 慢日志，必须手动配置生效。关键看 slowlog 和 request_slowlog_timeout 两个参数是否在 PHP-FPM 的 pool 配置里（如 /www/server/php/82/etc/php-fpm.d/www.conf）：
-
request_slowlog_timeout = 1s：设为非零值才触发记录，单位支持 s、ms（如500ms） -
slowlog = /www/wwwlogs/php_slow.log：路径需存在且 PHP-FPM 进程有写权限（建议用宝塔日志目录） - 必须重启 PHP-FPM 生效：
bt 16或在面板「软件商店 → PHP → 设置 → 服务」中重启
常见错误：只改了全局 php-fpm.conf，但实际生效的是 pool 级的 www.conf；或者路径写错导致日志根本没生成。
慢日志文件位置与实时查看方法
宝塔下 PHP-FPM 慢日志默认不在面板「网站日志」里显示，需手动定位：
- 路径通常为：
/www/wwwlogs/php_slow.log（取决于你配置的slowlog值） - 若找不到，用命令确认当前生效配置：
ps aux | grep php-fpm→ 找到 master 进程，再查它加载的 conf 路径，然后 grepslowlog - 实时追踪最新慢请求：
tail -f /www/wwwlogs/php_slow.log - 日志每条以
[timestamp] [pool www] pid XXXX开头，后面紧跟完整请求 URL 和耗时
注意：日志内容不含 POST 数据或敏感参数，但会记录完整 SCRIPT_FILENAME（即 PHP 文件绝对路径），这是定位函数入口的关键线索。
从慢日志反推耗时函数和调用链
慢日志本身不直接打印函数名，但包含足够线索定位瓶颈：
- 每条记录末尾有类似：
=> \think\App::run() /www/wwwroot/myapp/public/index.php:57 - 这说明耗时发生在
index.php第 57 行调用\think\App::run()时 - 接着顺藤摸瓜：打开该文件，看第 57 行附近是否包含数据库查询（
$model->select()）、远程请求（curl_exec）、大数组遍历等高开销操作
更准的方法是配合 Xdebug 或 Tracy，但慢日志能快速筛出「哪次请求慢」「慢在哪层文件」，避免盲目加断点。特别注意：
- 多个嵌套 include/require 时，日志只打最外层入口文件行号，需逐层检查被引入文件
- Laravel/ThinkPHP 等框架常把逻辑藏在中间件或事件监听器里，得结合路由和日志中的
REQUEST_URI一起分析 - 如果日志里反复出现同一
SCRIPT_FILENAME+ 同一行，基本可锁定问题函数
为什么开了慢日志却没记录？排查要点
最常见原因不是配置错，而是条件不满足：
- 请求未超时：设置的是
1s，但实际脚本执行 900ms 就结束了，不会记 - 日志路径不可写：
ls -l /www/wwwlogs/看属主是否为www，否则 PHP-FPM 写失败且无报错 - 使用了 OPcache 且脚本编译后首次运行快，后续请求变快，导致超时阈值失效
- Nginx 层设置了
fastcgi_read_timeout，比 PHP-FPM 的request_terminate_timeout更早中断连接，PHP 根本没机会记慢日志
验证是否真生效：写个测试脚本 /test-slow.php，内容为 ，然后访问它 —— 正常应立刻出现在慢日志里。
慢日志只是起点，真正耗时函数往往藏在框架封装之下；别只盯着日志里的那一行，要顺着 SCRIPT_FILENAME 和调用栈往深层文件里翻。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
