Opcache未生效主因是CLI下opcache.enable_cli=0或revalidate_freq=0却未设validate_timestamps=0；array_merge()循环追加导致O(n²)性能损耗；大结果集应逐行fetch避免内存溢出；json_encode()递归错误需用spl_object_hash检测循环引用。
为什么 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() 默认不检测深层引用，到一定嵌套就报这个错，且不提示具体哪一层。
立即学习“PHP免费学习笔记（深入）”；
- 先用
var_dump($data)看结构，重点检查对象属性是否互相指向 - 临时加保护：用
json_encode($data, JSON_PARTIAL_OUTPUT_ON_ERROR)（PHP 7.3+），出错字段转成null，至少不崩 - 更稳妥是预处理：递归遍历变量，用
spl_object_hash()记录已见对象 ID，遇到重复就打断或替换为标识符 - 别依赖
serialize()代替，它不解决传输/存储的可读性问题
PHP 的性能瓶颈往往不在算法，而在配置开关是否打开、基础操作是否误用、扩展行为是否被默认值误导。这些点改起来快，但漏掉一个，优化半天的代码可能白忙。
