PHP运行发热本质是CPU高负载，源于代码低效或配置不当；需用top/htop定位php-fpm进程、开启slowlog和OPcache、避免递归/全表遍历/同步外调/正则回溯，并调优php-fpm参数。
PHP 源码运行本身不会导致硬件发热——发热来自 CPU 长时间高负载执行编译、解析、执行过程，本质是代码效率或运行环境配置问题。
PHP 脚本 CPU 占用飙高时的定位方法
别急着换散热器，先确认是不是 PHP 进程真正在“烧” CPU。常见假象是 Web 服务器（如 Nginx）或数据库（如 MySQL）卡住，误判为 PHP 问题。
- 用
top或htop查看具体进程：关注php-fpm工作进程（不是php命令行进程）的 %CPU 占用 - 检查慢日志：确保
slowlog开启（slowlog = /var/log/php-fpm-slow.log），并设request_slowlog_timeout = 2s - 临时启用
xdebug的 profiler（仅调试）：生成cachegrind.out.*文件，用qcachegrind看函数耗时热点
常见 PHP 代码级“发热源”及修复
多数发热源于低效循环、未终止的递归、或阻塞式 I/O，而非语法错误。
- 无限/深层递归：比如在
__get()或__call()中意外触发自身，造成栈爆炸和 CPU 持续满载 - 全表遍历替代查询：用
foreach ($items as $item)遍历 10 万条数组结果，而不是加WHERE条件让数据库过滤 - 同步调用外部接口：比如在循环里反复
file_get_contents('https://api.example.com')，没设超时、没加缓存、没并发控制 - 正则回溯灾难：
preg_match('/^a+b*$/')类模式在恶意输入下可能指数级回溯，吃光 CPU
php-fpm 配置不当引发的资源争抢
默认配置适合开发，上线后若不调优，多个请求会争抢有限进程，排队等待+上下文切换反而推高 CPU 温度。
- 别用
pm = dynamic却把pm.max_children设成 100：小内存机器上实际并发撑不到 20，但系统不断 fork/kill 进程，开销巨大 - 检查
pm.status_path是否开启，并用curl http://localhost/status?full观察active processes和max active processes是否长期接近上限 -
request_terminate_timeout必须设（如30s）：防止单个脚本卡死拖垮整个池 - 静态模式（
pm = static）在容器或小流量场景更稳，避免动态伸缩带来的调度抖动
OPcache 配置不到位导致重复编译
每次请求都重新 tokenize + parse + compile，等于让 CPU 白干三遍。OPcache 不只是提速，更是降温关键。
- 确认
opcache.enable=1且opcache.enable_cli=0（CLI 下关掉，避免干扰调试） -
opcache.memory_consumption至少设为128（MB），太小会导致频繁踢出缓存，重编译 - 禁用
opcache.validate_timestamps上线后（设为0），否则每秒都在检查文件修改时间，IO+CPU 双浪费 - 注意
opcache.revalidate_freq：设为0时必须手动opcache_reset()或重启 fpm 才能热更代码
真正要盯住的，从来不是风扇转速，而是 php-fpm 日志里的 warning 行、slowlog 里重复出现的脚本路径、以及 opcache_get_status() 返回的 hit rate —— 低于 95% 就该查原因了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
