PHP脚本执行慢主因是I/O等待而非语法问题：HTTP请求未设超时（file_get_contents默认60秒、cURL需设CURLOPT_TIMEOUT等）、数据库未走索引（SELECT *、缺ORDER BY索引）、PHP-FPM配置不当（pm.max_children不合理）、OPcache未启用或内存不足。
PHP脚本执行慢，先看是不是 file_get_contents 或 cURL 卡住了
很多“PHP慢”其实不是PHP本身慢，而是发起外部HTTP请求时没设超时，一卡就是几十秒。比如调用支付回调、短信接口、第三方API，一旦对方响应延迟或挂掉，file_get_contents 默认会等足60秒才报错。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 所有
file_get_contents必须配stream_context_create，显式设'timeout' => 3（单位秒） - 改用
cURL更可控：必须设置CURLOPT_TIMEOUT（总耗时）和CURLOPT_CONNECTTIMEOUT（连接阶段） - 别在主流程里同步调第三方服务——能异步的丢进队列（如
Redis+ 后台worker），不能异步的至少加try/catch包住并快速失败
数据库查询拖慢响应，重点查 SELECT * 和缺失索引
一个没走索引的 SELECT * 查几万行，再快的服务器也扛不住。特别是带 ORDER BY、LIMIT 却没用上索引排序字段时，MySQL 可能要全表扫描+临时文件排序。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 开慢查询日志：
slow_query_log = ON，long_query_time = 0.5，直接揪出 >500ms 的SQL -
EXPLAIN每条高频查询：重点看type是否为ALL（全表扫描），key是否为NULL - 避免
SELECT *：只取需要字段；WHERE条件字段、ORDER BY字段、JOIN关联字段，该建联合索引就建，别只建单列
FPM配置不合理，导致高并发下请求排队
默认 pm = dynamic 配置在小内存机器上很容易撑爆，pm.max_children 设太高会OOM，设太低又让请求在FPM队列里干等，request_slowlog_timeout 不开就看不到谁在排队。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 算清楚可用内存：每个PHP进程约20–40MB（视扩展而定），
pm.max_children≤ 总内存 × 0.7 ÷ 30 - 打开慢日志：
request_slowlog_timeout = 1s，配合slowlog = /var/log/php-fpm-slow.log定位卡点 - 把
pm.status_path = /status配上，用curl http://your.app/status?full实时看哪些worker在忙、排队几个请求
OPcache没开或配置过保守，每次请求都重编译
没开OPcache时，每个PHP请求都要从磁盘读PHP文件、词法分析、语法分析、生成opcode——这部分开销在代码量大的项目里非常可观。开了但 opcache.memory_consumption 只设8MB，很快满，频繁踢出缓存，等于白开。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 确认已启用：
php -m | grep opcache，且opcache.enable=1在php.ini中生效 - 基础配置调高：
opcache.memory_consumption=128（单位MB），opcache.max_accelerated_files=20000，opcache.revalidate_freq=60 - 上线后别频繁改PHP文件——开发期可设
opcache.validate_timestamps=1，生产环境务必关掉（=0）
真正卡顿往往不在PHP语法多复杂，而在I/O等待、网络阻塞、锁竞争这些隐性环节。盯住日志、开对监控、别信“应该没问题”的直觉——slowlog 和 EXPLAIN 是最不骗人的两个东西。
