PHP脚本CPU飙高根本原因是代码导致CPU持续满负荷运转，常见于死循环、回溯灾难正则、无超时远程请求及同步I/O阻塞；定位需用top、strace和microtime打点，FPM场景应调优进程管理与超时配置。
PHP脚本执行时CPU飙高导致风扇狂转
根本原因不是PHP本身“发热”，而是某段代码让CPU持续满负荷运转，散热系统被动拉满。常见于死循环、低效正则、未设超时的远程请求、或大量同步I/O阻塞在单进程里。
-
while (true)或foreach套嵌过深且没退出条件，尤其在CLI脚本中容易被忽略 - 用
preg_match处理长文本时用了回溯灾难型正则（比如.*+.*+ 多重嵌套括号） -
file_get_contents请求外部API但对方响应慢，又没设stream_context_create的timeout参数 - CLI模式下用
sleep(0)模拟轮询，实际是空转抢CPU，应改用usleep(10000)（10ms）以上
如何快速定位耗CPU的PHP代码行
别靠猜，用系统工具直接看哪个进程/线程在吃资源，再结合PHP内置机制打点。
- 先运行
top -p $(pgrep -f "php.*your_script.php")，盯住%CPU列，确认是不是目标进程 - 对准PID执行
strace -p PID -c（按 Ctrl+C 结束），看统计里epoll_wait占比低、clock_gettime或brk高，基本是纯计算型热点 - 在可疑函数前后加
microtime(true)打点，例如：echo 'start: ' . microtime(true) . "\n";<br>heavy_calculation();<br>echo 'end: ' . microtime(true) . "\n";
- 避免用
xdebug在生产环境做性能分析——它会让CPU负载翻倍，只在开发机上开
PHP-FPM场景下风扇狂转的典型配置陷阱
FPM不是跑一次就完，它是常驻服务，配置不当会导致子进程集体“发疯”。重点不在PHP代码，而在池（pool）和全局调度。
-
pm = static且pm.max_children设得过大（比如100），并发稍高就全核跑满；建议改pm = dynamic，并调低pm.max_children（20–40视内存而定） -
request_terminate_timeout和request_slowlog_timeout没开，导致卡死请求不释放，子进程越积越多 -
slowlog路径写错（如目录不存在），日志写失败但FPM不报错，你根本看不到慢请求线索 - 检查
access.log里是否高频出现POST /api/sync类请求——这类接口若没做防重或限流，可能被前端反复触发
硬件温控不能靠PHP调，但能减少触发条件
Linux的温控策略（如 intel_pstate）由内核管理，PHP无权干预。你能做的，是降低CPU持续高负载的时间窗口，让风扇有喘息机会。
立即学习“PHP免费学习笔记（深入）”；
- 把批量任务从
webhook触发改成crontab+ionice -c 3运行，降低IO优先级 - 用
sysctl vm.swappiness=10减少交换，避免因内存压力间接推高CPU（缺内存时内核频繁回收页表） - 确认没有其他服务在抢资源：比如
docker stats看容器是否占满CPU，或systemd-analyze blame查开机慢服务 - 最易被忽略的一点：某些主板BIOS里，“节能模式”反而是风扇策略更激进，换成“平衡模式”有时比调PHP还管用
