开启opcache可避免PHP重复解析编译脚本，需配置opcache.enable=1、validate_timestamps=0（生产）、memory_consumption≥128MB；慎用opcache_reset()，推荐opcache_invalidate()单文件刷新。
用
开启字节码缓存，别只靠重启 PHP-FPM
PHP 每次请求都重新解析和编译脚本，是性能最大拖累之一。开启
后，PHP 会把编译后的 opcode 缓存在共享内存里，跳过重复编译过程。
实操建议：
确认已启用：
，没输出就需在
中取消
的注释
关键配置项必须设对：
、
（生产环境关掉文件时间戳校验）、
（至少 128MB）
开发环境可保留
，但务必配
，避免每次请求都检查文件改动
不要依赖
刷缓存——它会清空全部 opcode，高并发下易引发雪崩；改用
单文件刷新
数组遍历优先用
，别在
里反复调用
底层直接操作哈希表指针，比
+
快且安全。尤其当数组在循环中被修改时，
容易漏元素或死循环。
常见错误现象：
立即学习
“
PHP免费学习笔记（深入）
”；
，O(n²) 复杂度
用
：PHP 7.2+ 已废弃
，且内部指针易混乱
正确写法示例：
PHP 8.5.5
PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。
下载
数据库查询前先查缓存，别让
成为首页瓶颈
高频读接口不加缓存，再快的 MySQL 也扛不住并发。重点不是“要不要缓存”，而是“缓存什么”和“怎么失效”。
实操建议：
单条记录优先用
或
（进程内缓存）：例如
列表类数据慎用全量缓存：比如
返回几百条，缓存键建议带版本号
，更新时只改版本号，不删旧数据
避免缓存穿透：查不到的 ID（如
）也要缓存空值（
），防止恶意刷库
别在 ORM 的
外套一层缓存逻辑——很多框架（Laravel、ThinkPHP）已内置查询缓存，先看文档再造轮子
大文件上传或导出时禁用
，否则内存爆得悄无声息
PHP 默认开启
（通常 4096 字节），所有
、
都先写进内存缓冲区。导出万行 CSV 或生成 PDF 时，极易触发
。
解决方式很直接：
导出逻辑开头加：
，确保缓冲区清空
更彻底的做法：
+
（注意：仅限 CLI 或明确控制输出流的场景）
用
直接写响应体，配合
流式传输，内存占用恒定 O(1)
Web 服务器（Nginx/Apache）也要关掉自身的缓冲，比如 Nginx 的
，否则 PHP 吐了数据，Nginx 还在攒着
缓存键设计、opcode 失效策略、流式输出时机——这些地方不写代码也能出问题，反而最容易被忽略。
opcacheopcachephp -m | grep opcachephp.ini;extension=opcacheopcache.enable=1opcache.validate_timestamps=0opcache.memory_consumption=128opcache.validate_timestamps=1opcache.revalidate_freq=2opcache_reset()opcache_invalidate($script, true)foreachforcount()foreachforcount()forfor ($i = 0; $i ：每次迭代都调用 count()while (list(, $v) = each($arr))each()foreach ($users as $user) {
// 直接用 $user，无需索引
}
// 或需键值时：
foreach ($config as $key => $value) {
if ($key === 'timeout') { ... }
}SELECT * FROM usersRedisAPCuapcu_store('user_123', $row, 3600)get_all_active_posts()posts_v2user_id = 9999999apcu_store('user_9999999', null, 60)find()output_bufferingoutput_bufferingechoprintFatal error: Allowed memory size exhaustedif (ob_get_level()) { ob_end_flush(); }ob_end_clean();ini_set('output_buffering', 'Off');fopen('php://output', 'w')fpassthru()fastcgi_buffering off;