PHP内存管理需通过memory_get_usage(true)和gc_collect_cycles()反复验证，关注引用、循环引用及扩展资源泄漏，结合xdebug_debug_zval()、生成器等手段精准定位与释放内存。
PHP内存管理不是靠背概念学会的，得在memory_get_usage(true)和gc_collect_cycles()之间反复验证，才能看清变量、引用、循环和扩展层资源的真实行为。
怎么确认当前内存到底被谁占着？
别只调memory_get_usage()——它默认不统计已关闭但未清理的cURL句柄、PDO预处理缓存、GD图像资源等。这些“看不见的内存”常让RSS持续上涨，而脚本里却查不到大变量。
- 统一用
memory_get_usage(true)，加true才包含内部缓冲区 - 关键节点打点：函数入口、循环每次迭代前后、
file_get_contents()之后、json_decode()之后 - 对比差值比看绝对值更有意义，比如
echo "After JSON: " . (memory_get_usage(true) - $before) . " bytes\n"; - CLI下用
memory_get_peak_usage(true)看峰值，它反映真实压力，含未释放的循环引用
为什么unset()了内存还不降？
常见于三种情况：引用未断、循环引用未触发GC、扩展资源泄漏。尤其是$a = &$b后只unset($a)，$b仍持有全部数据；或者对象间互相$obj1->ref = $obj2又$obj2->ref = $obj1，引用计数永远不归零。
- 解除引用必须
unset($a); unset($b)，或统一设为null - 怀疑循环引用时，在可疑循环末尾加
gc_collect_cycles()，观察内存是否回落——不回落就是真环 - 用
xdebug_debug_zval()检查变量实际引用计数，比如xdebug_debug_zval('my_array')会显示refcount=2 is_ref=1 - 如果
gc_collect_cycles()返回0且内存不降，大概率是扩展层泄漏（如未curl_close()）
大数组/大文件处理时最省内存的写法
不是“压缩数据”，而是切断加载链、复用结构、避免隐式拷贝。PHP天生不适合全量加载，硬要撑，就得绕开惯性操作。
立即学习“PHP免费学习笔记（深入）”；
- 读CSV别用
file()+str_getcsv()，改用fgetcsv($fp)逐行解析 - PDO查大数据集，禁用缓冲：
['PDO::MYSQL_ATTR_USE_BUFFERED_QUERY' => false]，否则结果全进PHP内存 - 拼接大量字符串别用
$str .= $chunk（每次重分配），改用array_push($parts, $chunk)再implode('', $parts) - 解析大JSON优先用
json_decode($json, false)（返回对象），比true（嵌套数组）省内存约15%，键名不重复存储 - 写日志或导出文件别用
file_put_contents($path, $line, FILE_APPEND)，改用fopen(..., 'a')+fwrite()+fclose()
生成器（Generator）什么时候必须用？
当你函数的返回值是一个可能含数千、数万甚至更多元素的集合，并且调用方是foreach遍历时，yield不是“可选优化”，而是避免OOM的必要手段。
- 数据库分页拉取：不用
fetchAll()，改写yield $stmt->fetch()逐条产出 - 读大文件：用
while (($line = fgets($fp)) !== false) { yield $line; } - API分页聚合：每页
curl_exec()后yield解析结果，不累积 - 注意：
yield函数不能被array_map或array_filter直接消费，要用iterator_to_array()前先确认规模
真正卡住人的从来不是语法，而是变量生命周期和扩展资源的隐式绑定——比如一个没fclose()的文件指针，或一个没unset()的引用数组，在长循环里会悄悄吃掉几百MB。盯住memory_get_usage(true)的差值，比猜更可靠。
