php内存占用高需从变量生命周期、数据加载方式和缓存机制入手：1. unset后内存不降因gc不即时，需结合null赋值、gc_collect_cycles()及debug_zval_dump排查引用；2. yield生成器可省90%内存，实现流式处理；3. opcache配置不当反增内存，应依opcache_get_status()调优并禁用xdebug。
PHP内存占用高，通常不是因为单行代码写错，而是变量生命周期失控、数据加载方式粗放、或缓存机制没起效。直接调大memory_limit只是掩盖问题，真正要做的，是让每MB内存都用在刀刃上。
为什么 unset($bigArray) 后内存没立刻降下来
PHP的垃圾回收（GC）不保证立即释放内存，尤其当存在循环引用、或变量仍被引用（比如通过&$ref）、或在对象属性中隐式持有时，unset()只是断开一个引用，不代表内存归还。更关键的是：CLI脚本中，未显式释放的大数组可能持续占满整个执行周期。
- 确认是否真被引用：用
debug_zval_dump($var)看refcount和is_ref值 - 手动触发回收：
gc_collect_cycles()在批量处理后调用一次 - 释放前先设为
null：$bigArray = null;比单纯unset()更明确向GC传递意图 - 避免在循环里累积：
$list[] = $item会不断扩容数组；改用生成器或分批array_chunk()
yield 生成器为什么能省 90% 内存
传统函数返回array时，必须把全部数据加载进内存再返回；而yield是“按需产出”，每次只在迭代器取值时计算并返回一个元素，内存占用基本恒定——哪怕处理百万行CSV或数据库结果集。
- 文件逐行读取别用
file()：function readCsvLines($path) { $fp = fopen($path, 'r'); while (($line = fgets($fp)) !== false) { yield str_getcsv($line); } fclose($fp); } - 数据库查询封装成生成器：
PDO::FETCH_ASSOC+yield $stmt->fetch()，禁用PDO::FETCH_ALL - 注意不要在生成器内保留大闭包或对象引用，否则会阻碍GC
OPcache 配置不当反而加重内存压力
OPcache本身要占内存，但如果opcache.max_accelerated_files太小，或opcache.revalidate_freq设得太低，会导致频繁淘汰+重新编译，不仅浪费CPU，还会推高峰值内存——因为旧opcode还没释放，新脚本又在加载。
- 查当前命中率：
opcache_get_status()['opcache_statistics']['hit_rate']，低于 95% 就该调优 - 设足够大的缓存空间：
opcache.memory_consumption=256（单位 MB），小项目 128 起步 - 生产环境关掉验证：
opcache.validate_timestamps=0，靠opcache_reset()或部署时清缓存 - CLI脚本也需启用：
opcache.enable_cli=1，否则命令行任务完全没受益
监控 memory_get_usage() 为什么总不准
memory_get_usage()默认只统计当前脚本分配的内存，不含未释放的循环引用、OPcache占用、或Zend引擎内部结构。真正反映压力的是memory_get_peak_usage(true)——它包含所有已分配但尚未归还的内存，更接近OS看到的RSS值。
- 在关键节点打点：
echo "After parse: " . round(memory_get_usage() / 1024 / 1024, 2) . " MB\n"; - 对比
memory_get_peak_usage(true)和memory_get_usage()差值，若远大于 1MB，大概率有循环引用 - 生产环境禁用
xdebug——它会让memory_get_usage()报告虚高，且自身吃掉几十MB - 用
ps aux --sort=-%mem | head -10从系统层确认真实内存大户
最常被忽略的一点：内存问题 rarely 是孤立的。一个foreach里没unset的临时数组，叠加一个没关的display_errors，再加一个require_once反复加载的配置类，三者叠加就可能突破阈值。优化得从调用链最末端开始切口，而不是盯着memory_limit硬扛。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
