PHP代码优化技巧：提升执行速度方法

本文深入剖析PHP性能优化中极易被忽视却影响巨大的四大实战陷阱：Opcache在CLI模式下默认失效及配置误区、array_merge()在循环中引发的平方级性能衰减、大结果集查询时内存溢出风险与流式处理策略，以及json_encode()因循环引用导致的递归错误定位与防御方案；每一点都直击生产环境常见“慢得莫名其妙”的根源，用具体配置参数、代码对比和底层机制解释为何看似正确的写法反而拖垮系统，并提供开箱即用的修复建议——优化不靠玄学，而在于厘清默认行为、避开隐性开销、善用语言特性。

为什么 opcache.enable=1 开了但没生效？

PHP 7.0+ 默认带 Opcache，但很多环境实际没跑起来。常见原因是配置被覆盖：CLI 模式下 opcache.enable_cli 默认是 0，Web SAPI（如 FPM）才默认启用；或者 opcache.revalidate_freq 设成 0 后，又没配 opcache.validate_timestamps=0，导致每次请求都重校验文件时间戳，反而拖慢速度。

• 检查是否真启用：php -i | grep opcache.enabled（CLI）或输出 phpinfo() 看 Web 环境
• 生产环境务必设 opcache.validate_timestamps=0，配合 opcache.revalidate_freq=0 或干脆删掉后者
• opcache.memory_consumption 至少调到 128（MB），小项目也别低于 64
• 避免在部署后手动 touch 文件或改权限触发重编译——Opcache 对文件 inode 和权限变化敏感

array_merge() 在循环里拼数组有多伤性能？

不是语法错，是典型隐性开销：每次调用都复制全部元素，时间复杂度 O(n+m)，嵌套循环里变成 O(n²)。尤其处理上千条记录时，比直接用 [] 追加慢 5–10 倍。

• 循环中追加用 $arr[] = $item，不是 $arr = array_merge($arr, [$item])
• 要合并多个已知数组，array_merge($a, $b, $c) 没问题；但动态数量时，先收集所有子数组再一次性 array_merge(...$list)（PHP 5.6+）
• array_push() 和 [] 性能几乎一样，后者更直观；别用 array_merge() 替代追加逻辑

MySQL 查询结果用 fetch_all(MYSQLI_ASSOC) 还是逐行 fetch_assoc()？

取决于数据量和后续操作。大结果集（比如 >5000 行）用 fetch_all() 会一次性把全部数据载入内存，可能触发 memory_limit；而逐行处理可流式释放，适合导出、统计等场景。

• 小结果（<100 行）：fetch_all(MYSQLI_ASSOC) 省事，函数调用开销可忽略
• 大结果或内存敏感场景：用 while ($row = $result->fetch_assoc()) { ... }，避免中间数组膨胀
• 注意 mysqli 默认是缓冲查询（buffered），fetch_all() 和逐行在底层都已取完数据；真要流式得关缓冲：mysqli_query($conn, 'SELECT ...', MYSQLI_USE_RESULT)，但此时不能执行新查询直到结果集关闭

json_encode() 报 “Recursion detected” 怎么快速定位？

不是 JSON 格式问题，是 PHP 变量里存在循环引用（比如对象 A 持有 B，B 又持有 A）。json_encode() 默认不检测深层引用，到一定嵌套就报这个错，且不提示具体哪一层。

• 先用 var_dump($data) 看结构，重点检查对象属性是否互相指向
• 临时加保护：用 json_encode($data, JSON_PARTIAL_OUTPUT_ON_ERROR)（PHP 7.3+），出错字段转成 null，至少不崩
• 更稳妥是预处理：递归遍历变量，用 spl_object_hash() 记录已见对象 ID，遇到重复就打断或替换为标识符
• 别依赖 serialize() 代替，它不解决传输/存储的可读性问题

PHP 的性能瓶颈往往不在算法，而在配置开关是否打开、基础操作是否误用、扩展行为是否被默认值误导。这些点改起来快，但漏掉一个，优化半天的代码可能白忙。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~