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