php-fpm卡顿主因是子进程耗尽而非代码问题，需检查active processes是否达max_children、验证opcache是否生效、排查n+1查询及xdebug隐性加载。
看一眼就知道是不是PHP-FPM卡住了
很多“网站卡顿”其实根本不是代码问题，而是 PHP-FPM 子进程全在排队等处理——你刷新页面要等 3 秒以上，top 里却看不到 PHP 进程占 CPU，反而 nginx 的 worker 进程大量处于 sleeping 状态，这就是典型 FPM 响应不过来。
- 立刻执行：
sudo systemctl status php-fpm或ps aux | grep 'php-fpm:'，看活跃子进程数是否接近pm.max_children - 查请求堆积：
curl -s http://127.0.0.1/status?full | grep 'processes$'（需开启pm.status_path） - 如果
active processes长期等于max children，且slow requests持续增长，说明 FPM 池已满，必须调参或查慢脚本
别急着加机器——90% 的情况是某个接口死循环、没设超时的 cURL、或数据库锁表，导致一个请求卡住整个 worker。
用 opcache_get_status() 两秒确认字节码缓存是否真在干活
很多人以为开了 opcache.enable=1 就万事大吉，但实际中常因配置错位或缓存击穿导致 OPcache 形同虚设。最直接的验证方式不是看 phpinfo，而是调用函数实时查状态。
- 写个临时脚本：
<?php $status = opcache_get_status(); echo "opcache_enabled: " . ($status['opcache_enabled'] ? 'yes' : 'no') . "\n"; echo "memory_usage: " . round($status['memory_usage']['used_memory']/1024/1024, 1) . " MB\n"; echo "cached_scripts: " . $status['opcache_statistics']['num_cached_scripts'] . "\n"; ?>
- 关键看
num_cached_scripts：新部署后首次访问应快速上升；若长期为 0 或只缓存个位数文件，检查opcache.restrict_api是否误配，或opcache.validate_timestamps=0在开发环境没关（导致改完代码不生效还误以为缓存失效） - 注意
opcache.max_accelerated_files：设太小（如默认 2000）会导致频繁淘汰，尤其 Composer 自动加载文件多的项目，建议至少设为20000
数据库 N+1 查询，slow_query_log 可能根本抓不到
MySQL 慢日志只记录单条 SQL 超时，但 N+1 是 100 个 20ms 的查询连发——总耗时 2 秒，每个都躲过 long_query_time=1，结果页面卡死，日志却干干净净。
立即学习“PHP免费学习笔记（深入）”；
- 真正有效的办法：在 PHP 层埋点统计查询次数。Laravel 用户可开
DB::enableQueryLog()；原生 PDO 可封装query()方法，在全局记录$this->queryCount++ - 上线前必做：在关键页面末尾加一行：
<!-- queries: <?= $queryCount ?? 0 ?> -->
，肉眼一扫就知道有没有异常（比如首页打出 127 次查询） - 修复时不光加索引——更关键的是把循环内
SELECT * FROM posts WHERE user_id = ?改成一次SELECT * FROM posts WHERE user_id IN (1,2,3...)，再用 PHP 关联组装
别让 Xdebug 在生产环境偷偷吃掉 300% 的响应时间
很多团队说“我们没开 Xdebug”，但检查 php --ini 会发现 xdebug.so 仍被加载，只是 xdebug.mode 设成了 off——这依然会让每次请求多花 50~200ms 初始化调试器上下文。
- 终极判断命令：
php -m | grep xdebug，只要输出非空，Xdebug 就在加载；要彻底禁用，必须注释掉zend_extension=xdebug.so这行 - 开发机也别无脑开全功能：把
xdebug.mode=debug,develop改成xdebug.mode=debug，并确保xdebug.start_with_request=trigger，否则每次请求都在扫描断点 - 一个容易被忽略的坑：
xdebug.log如果指向磁盘文件（尤其 NFS 或低速盘），高并发下 I/O 会直接拖垮整个 PHP-FPM 池
性能排查最怕“以为修好了”，实际上只是把症状压下去了。比如调大 pm.max_children 暂时缓解排队，但那个卡住的慢查询还在——下次流量高峰它会立刻回来。真正的快，是让每个请求从进来到返回，路径清晰、无盲区、可度量。
