opcache未启用或配置不当是php性能瓶颈主因；需用opcache_get_status()验证命中率，调大opcache.max_accelerated_files，关闭opcache.validate_timestamps，开启opcache.enable_cli；循环中避免count()/strlen()、字符串拼接用数组+implode、echo多变量用逗号分隔、静态方法声明为static、禁用@错误抑制符。
OPcache 不开，其他优化基本白忙——绝大多数 PHP 性能问题，根源不在代码逻辑，而在每次请求都重复编译脚本。
怎么确认 OPcache 真的在工作
别只看 phpinfo 里显示 enabled 就以为万事大吉。很多环境（尤其是本地开发或一键包如 phpStudy、phpEnv）默认开了但参数极保守，缓存很快被踢出，等于没开。
- 用
opcache_get_status()查真实命中率：opcache_get_status()['opcache_statistics']['hits'] / ($hits + $misses)，低于 90% 就得调参 -
opcache.max_accelerated_files默认常是 2000 或 4000，中型项目（含 vendor）轻松超 1 万文件，缓存频繁失效 -
opcache.validate_timestamps=0必须关（生产），否则每请求都 stat 文件，I/O 拖垮性能 - CLI 脚本也得开：
opcache.enable_cli=1，否则 PHPUnit 或队列任务照样慢
循环里别反复调 count() 和 strlen()
这不是“写法优雅”问题，是实打实的性能损耗：对 10 万元素数组，for ($i = 0; $i 每轮都调一次 <code>count()，多出近 10 万次函数调用开销。
- 提前缓存：
$len = count($arr); for ($i = 0; $i - 判断字符串长度？
isset($str[10])比strlen($str) > 10快 18 倍——因为isset()是语言结构，不进函数栈 - 空字符串检查直接用
$str !== ''，比strlen($str) > 0少一次调用
字符串拼接别用 .= 在大循环里
每次 $log .= $line 都触发内存重分配 + 全量复制，数据量一过几万字节，耗时呈指数增长。日志组装、HTML 模板生成、CSV 导出最易踩坑。
- 改用数组收集：
$parts[] = $line;，最后implode('', $parts) - 输出多个变量时，
echo $a, $b, $c比echo $a . $b . $c少一次中间字符串构造 - 纯静态字符串优先用单引号：
'hello'不解析变量，比双引号快；含变量再用双引号或插值
require_once 和自动加载是启动阶段隐形杀手
每个 require_once 都要遍历 include_path 查文件是否已加载，路径深、文件多时，光是文件系统查找就能吃掉几十毫秒。Composer 自动加载器若没优化，也会反复 stat。
- 用绝对路径包含：
require_once __DIR__ . '/config.php';，跳过路径搜索 - Composer 项目必须跑：
composer dump-autoload --optimize（PHP 7.4+ 推荐--classmap-authoritative） - 高频工具类方法尽量声明为
static，实测提速近 4 倍（省去对象绑定开销） - 禁用
@错误抑制符——它强制 PHP 进入异常捕获路径，比直接报错慢一个数量级
display_errors、或者把配置文件放在 json_decode(file_get_contents()) 里反复读。优化得从这些点下手，才立竿见影。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
