FPM慢日志可在请求达到设定条件时记录执行栈，帮助定位当时停留的位置，但它不是完整性能剖析，也不能只凭出现某个插件路径就认定该插件消耗了全部时间。需要关联请求、等待对象与其他日志。
先明确采样条件和目标池
记录慢日志触发阈值、对应FPM池与运行时段，确认问题请求确实进入该环境。阈值过高可能漏掉频繁中等慢请求，过低则产生大量记录；不能直接照搬其他服务器参数，也不要把未触发慢日志解释成没有性能问题。
将栈位置对应到真实操作
执行栈可能停在数据库调用、外部HTTP、文件读写或插件函数中。路径说明调用关系和采样瞬间，不自动区分CPU计算与等待。结合访问日志中的URL、时间和请求标识，确定是哪一个页面、后台动作或任务，而不是泛称整个网站慢。
补上对应资源的证据
若栈指向数据库，查相关查询和锁；若是外部接口，核对连接、响应与重试；文件操作则看磁盘和权限。不要因为调用发生在某插件中就立即卸载生产插件，也不要用提高超时掩盖长期等待。先在可控环境形成可重复条件。
保护日志并验证修复范围
慢日志可能暴露服务器路径和业务调用细节，存放与导出应受控。采取小范围修正后，以同类请求观察实际耗时、错误与慢日志变化。一次未采到记录不足以证明长期恢复，需说明观察窗口与仍未验证的并发条件。
关键区别
慢日志：记录达到条件的执行栈；不是完整耗时分解。
插件路径：说明调用位置；不能独立证明根因。
关联证据：请求和资源日志；帮助区分计算与等待。
怎样确认处理到位
目标请求的等待原因有交叉证据，修正后同条件耗时和错误改善，日志存储未暴露敏感路径，结论保留采样边界。
容易误判的边界
本篇不把慢日志当自动归责工具，也不建议不看业务依赖就停用生产插件或无限延长请求时限。
