PHP 7.2 内存优化需精准设置 memory_limit、主动管理变量生命周期、善用生成器与 GC 机制，并避免隐式内存陷阱。
PHP 7.2 的内存分配优化，核心在于控制单脚本内存上限、减少运行时冗余开销、及时释放无用内存，并配合底层机制合理调用。不是简单调高 memory_limit，而是让每一分内存都用在刀刃上。
精准设置 memory_limit，避免“一刀切”
默认值（如 128M 或 256M）常被直接沿用，但实际业务差异极大。高并发小接口可能 64M 足够，而报表导出类脚本临时需 512M。建议：
- 先用
memory_get_usage(true)和memory_get_peak_usage(true)在关键路径埋点，观察真实占用 - 按场景分级配置：Web 请求设为 128M，CLI 批处理脚本通过
ini_set('memory_limit', '512M')动态提升 - 禁用无限内存（
-1），防止失控脚本拖垮整机；生产环境推荐显式设为带单位的值，如192M
主动管理变量生命周期
PHP 使用引用计数 + 周期性 GC，但大对象或循环引用不会立刻释放。尤其在长循环、大数组遍历中：
- 对中间结果大数组（如批量查库返回的 10 万条记录），处理完立即
unset($data) - 避免在循环内反复
$arr[] = $item累积——改用生成器（yield）逐条产出，内存占用可从百 MB 降至 KB 级 - 开启并信任 GC：确认
gc_enabled()返回 true；对长时间运行的 CLI 脚本，每处理 N 条后手动调用gc_collect_cycles()
用对语法和函数，避开隐式内存陷阱
某些写法看似简洁，实则触发多次内存拷贝或全量加载：
立即学习“PHP免费学习笔记（深入）”；
- 循环里别写
for ($i = 0; $i ——<code>count()每次都重新计算，且 PHP 可能复制数组哈希表；应提前存$len = count($arr) - 合并索引数组优先用扩展运算符
[...$a, ...$b]，比array_merge($a, $b)更快、内存更省（编译期展开，无函数调用开销） - 判断键存在用
isset($arr['key'])而非array_key_exists()，前者快 3 倍以上，且不触发额外哈希查找
启用 OPcache 并合理配置
OPcache 不仅加速执行，还显著降低内存重复分配压力——字节码只加载一次，后续请求共享内存页：
- 确保
opcache.enable=1、opcache.memory_consumption=128（单位 MB，根据项目文件数调至 96–256） - 设
opcache.max_accelerated_files≥ 项目 PHP 文件总数（可用find /app -name "*.php" | wc -l估算） - 开发环境关掉
opcache.revalidate_freq=0，生产环境设为 60（秒），平衡热更新与稳定性
