PHP性能瓶颈多源于字符串拼接、循环内函数调用、数组遍历及文件包含路径；应缓存count()、strlen()等结果，避免重复开销。
PHP代码性能瓶颈，八成出在字符串拼接、循环内函数调用、数组遍历方式和文件包含路径上——不是算法太差，而是这些操作在高频场景下被反复放大了开销。
循环里别反复调用 count() 或 strlen()
常见错误是写 for ($i = 0; $i ，每次迭代都重新计算数组长度；对字符串做 <code>if (strlen($s) > 10) 也同理。PHP 每次调用函数都要走符号查找、参数压栈、返回值拷贝，纯浪费。
- 提前缓存结果：
$len = count($arr); for ($i = 0; $i - 判断字符串长度够不够？用
!isset($s[10])替代strlen($s) ，快约 18 倍——<code>isset()是语言结构，不进函数调用流程 - 如果只是检查是否存在某个索引位置，
isset($arr[999])比array_key_exists(999, $arr)快 3 倍以上
字符串拼接优先用 implode() 而非 .=
.= 在大循环中拼接日志、HTML 或 CSV 行时，每次都会重新分配内存并复制整个字符串。数据量一过万，耗时就明显跳涨。
- 改用数组收集：
$parts[] = $chunk;，最后$result = implode('', $parts); - 输出多个变量时，
echo $a, $b, $c;比echo $a . $b . $c;少一次字符串合并，更轻量 - 纯字面量字符串一律用单引号：
'hello world'不解析变量和转义，比双引号快
避免动态调用和低效自动加载
call_user_func()、$func_name() 这类动态调用必须做运行时符号查找，比直接调用慢一个数量级；require_once 在深目录或大量文件场景下，每次都要检查已加载列表，I/O 和哈希查找开销陡增。
立即学习“PHP免费学习笔记（深入）”；
- 高频方法尽量声明为
static，实测提速近 4 倍 - 用绝对路径包含文件：
require '/var/www/app/config.php';，跳过include_path逐个扫描 - Composer 自动加载务必加
--optimize（即composer dump-autoload -o），生成静态映射表 - 配置数据别放 JSON/YAML 里解析，直接写成返回数组的
config.php文件，OPcache 可直接缓存编译结果
OPcache 不是“开了就行”，关键参数必须调
默认 opcache.max_accelerated_files = 2000，中小项目可能够用，但 Composer vendor 目录一展开就超；opcache.memory_consumption 默认 64M，现代项目打满是常态——缓存踢出频繁，反而增加编译压力。
- 设
opcache.max_accelerated_files至少 20000（根据find vendor/ -name '*.php' | wc -l估算） -
opcache.memory_consumption推荐 128–256M，CLI 场景别忘了开opcache.enable_cli=1 -
opcache.revalidate_freq=60表示每 60 秒检查一次文件更新，生产环境可设为 0（配合部署时手动opcache_reset()） - 禁用
@错误抑制符——它强制 PHP 进入异常捕获路径，比直接报错慢一个数量级
真正拖慢 PHP 的，往往不是你写的业务逻辑，而是那些看起来无害的操作：循环里查数组长度、用双引号包死变量、忘了关 display_errors、或者把路由配置塞进 YAML 解析器里跑。优化要盯住高频路径，而不是堆砌技巧。
