PHP性能优化核心在代码精简、OPcache调优、I/O阻塞规避和FPM进程模型匹配四方面；须避免循环内同步I/O、启用OPcache并禁用时间戳验证、按请求特征选FPM模式、慎用低效数组函数，并以xhprof等工具定位真实瓶颈。
PHP 性能优化不是“加缓存”或“换 PHP 版本”一句话能解决的，真正见效的点集中在代码逻辑精简、OPcache 配置调优、I/O 阻塞规避和 FPM 进程模型匹配这四块。其他所谓“优化”多数在真实业务中收益微乎其微，甚至引入新问题。
避免在循环里做 file_get_contents 或 curl_exec
这是线上最常见却最容易被忽略的性能黑洞：一次请求触发几十次同步 HTTP 调用或文件读取，响应时间直接从 20ms 拉到 2s+，且无法通过增加 CPU 解决。
- 把多次外部请求合并为批量接口（如用
curl_multi_exec替代单个curl_exec） - 静态资源（如 JSON 配置）改用
include或require_once加载，而非file_get_contents+json_decode - 数据库查多条记录时，别用
foreach+$pdo->query("SELECT * FROM t WHERE id = $id")，改写成WHERE id IN (1,2,3...)
OPcache 必须启用且禁用验证时间戳
默认 PHP 安装后 OPcache 是开启的，但 opcache.validate_timestamps=1（开发环境默认值）会让每次请求都检查 PHP 文件是否被修改，等效于关闭缓存。
- 生产环境务必设为
opcache.validate_timestamps=0，配合部署时opcache_reset()或systemctl reload php-fpm -
opcache.memory_consumption至少设为128（单位 MB），小项目 64MB 也够，但低于 32MB 容易频繁满而失效 - 不要开
opcache.fast_shutdown=1—— 它在 PHP 7.4+ 已废弃，且在某些扩展下引发内存泄漏
PHP-FPM 进程管理要匹配实际并发模型
用 static 还是 dynamic？关键看请求特征：短平快（如 API）适合 static；长尾请求（如导出、上传回调）必须用 ondemand 或调大 dynamic 的 max_children，否则会排队卡住。
立即学习“PHP免费学习笔记（深入）”；
-
pm = dynamic时，pm.max_children别按峰值 QPS × 平均耗时硬算，要留 30% 余量防突发抖动 -
pm.start_servers和pm.min_spare_servers值太小会导致冷启动延迟，建议设为max_children的 50%~70% - 如果日志里频繁出现
"seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers)"，说明当前空闲进程不足，不是 CPU 不够
数组操作别滥用 array_merge 和 array_keys
这两个函数在大数据量下是隐式性能杀手：array_merge 会重建完整键值映射，array_keys 默认返回数字索引并重排，复杂度 O(n)，且产生临时数组。
- 合并配置数组优先用
+（加号）运算符，它保留左侧键，不重排，也不校验类型 - 判断键是否存在，用
isset($arr['key'])而非in_array('key', array_keys($arr)) - 需要去重的整数 ID 列表，用
array_flip+array_keys比array_unique快 2~3 倍（因底层哈希表更直接）
真正卡住 PHP 性能的，往往不是语法多慢，而是开发者没意识到某行代码在十万次请求里放大成了十秒阻塞。每处优化前，先用 xhprof 或 Blackfire 确认瓶颈在哪儿——90% 的“优化”根本没跑在热路径上。
