PHP慢日志需结合时间戳、调用栈、请求路径三者对齐才能准确定位瓶颈；确认其生效须检查配置加载、阈值单位、服务状态、文件权限，并聚焦backtrace而非仅script_filename。
PHP慢日志不是“看一眼就知道哪慢”，它必须和时间戳、调用栈、请求路径三者对齐才能定位真实瓶颈。
怎么确认 slowlog 真的在写入
很多人以为配了 slowlog 就万事大吉，结果排查时发现日志空空如也——最常见原因是没重启 PHP-FPM 或配置压根没生效。
- 先执行
php --ini确认正在加载的php.ini路径，再 greprequest_slowlog_timeout和slowlog看是否被注释或拼错 - 检查
request_slowlog_timeout值（比如设成2），注意单位是秒，不是毫秒；低于 1 秒的阈值在高并发下容易刷屏，但设太高又漏掉真实问题 - 用
systemctl status php-fpm看服务是否正常运行，再手动触发一个明显慢的脚本（如sleep(3)）验证日志是否落盘 - 权限问题常被忽略：确保 PHP-FPM worker 进程用户（如
www-data）对slowlog文件路径有写权限，否则静默失败
日志里看到的 “script_filename” 不等于问题根源
慢日志第一行通常带 script_filename，但它只是入口文件，真正拖慢的可能是它 include 的某个类、某次 PDO 查询、甚至 Composer 自动加载里的反射操作。
- 重点看日志中紧随其后的
backtrace（如果有）或function字段，而不是只盯着/var/www/index.php - 没有 backtrace？说明 PHP 配置里
log_errors开了但display_errors关了，或者用了某些框架屏蔽了堆栈——此时需配合 Xdebug 或debug_print_backtrace()临时补全 - 常见陷阱：日志显示
require_once耗时长，实际是该文件里隐式执行了未缓存的file_get_contents或远程 cURL，而非 require 本身慢
用 awk + grep 快速筛出高频慢点
人工翻日志效率极低，但不需要上 ELK 也能快速聚焦。核心思路是按「脚本路径 + 行号」聚合，看哪些位置反复出现。
立即学习“PHP免费学习笔记（深入）”；
- 提取最常出现的慢点：
awk -F'"' '/script_filename/ {print $2} /^$/ {print ""}' /var/log/php-slow.log | sort | uniq -c | sort -nr | head -10 - 查某接口是否总慢：
grep -A 5 "GET /api/user/profile" /var/log/php-slow.log（注意时间窗口要对齐 access.log） - 过滤掉干扰项：慢日志里常混着
Unknown: script timed out或PHP message: PHP Warning，它们和request_slowlog_timeout无关，别误判 - 别直接
cat大日志：超 100MB 的文件用tail -n 10000先看近期，避免 OOM 或卡死终端
为什么加了索引、优化了 SQL，slowlog 还在报同一脚本
因为 PHP 慢日志记录的是整个请求生命周期，数据库只是其中一环。哪怕 SQL 执行只要 5ms，前面 autoload 加载 50 个类、后面 JSON 编码 10MB 数组、或者 session_write_close() 卡住，都会让整条请求超阈值。
- 用
microtime(true)在关键位置打点，对比日志里标出的耗时和你代码里测的是否吻合，能快速排除“到底是哪一段” - 检查是否启用了
opcache.enable_cli=1（CLI 场景）或opcache.revalidate_freq=0（开发环境常误配），否则每次请求都重编译，白白消耗 CPU - 留意
memory_limit接近上限时，PHP 会频繁触发垃圾回收，表现为日志里没明显慢函数，但整体响应飘忽——此时error_log可能有Allowed memory size exhausted提示
真正难的不是找到哪一行慢，而是判断「这一行慢，是因为它本该就慢，还是因为上游传了错误参数、下游服务抖动、或配置漏了一处」。日志只是线索，不是结论。
