php无法直接测量单个变量内存，需用memory_get_usage()前后差值估算，但受写时复制、引用计数等机制影响，实测需配合gc_collect_cycles()、独立作用域和强制复制。
怎么用 memory_get_usage() 看单个变量占多少内存
PHP 没有直接“查某个变量用了多少内存”的函数，memory_get_usage() 返回的是整个脚本当前的内存总量。想估算单个变量，得靠前后差值——但这个差值很容易被 PHP 的写时复制（Copy-on-Write）和引用计数机制干扰。
实操建议：
- 确保变量是独立创建、未被其他变量引用，否则差值会偏低；
- 在干净作用域里测，比如封装进一个函数并立即返回，避免闭包或全局污染；
- 调用前加
gc_collect_cycles()，防止上一轮未回收的垃圾影响读数； - 对大数组或对象，差值可能比真实占用小 10%–30%，因为部分结构（如哈希表桶）是共享或延迟分配的。
示例：
<?php
function getVarMem($var) {
gc_collect_cycles();
$before = memory_get_usage();
$tmp = $var; // 强制复制（对非引用类型）
$after = memory_get_usage();
return $after - $before;
}
echo getVarMem(str_repeat('a', 1024*1024)); // 约 1MB
为什么 debug_zval_dump() 显示的 refcount 不等于内存实际开销
这个函数只告诉你引用计数和是否为引用，但不反映底层数据结构的内存布局。比如一个 array 即使 refcount=1，也可能共享了 zend_array 的 hash table 头部，或复用了已分配的 bucket 内存块。
常见错误现象：
立即学习“PHP免费学习笔记（深入）”；
- 看到
refcount=1就以为变量独占全部内存，结果 unset 后内存没明显下降； - 对字符串反复赋值后
debug_zval_dump()显示is_ref=0，误判为无共享，其实 interned string 可能已被全局缓存； - 对象属性里嵌套数组时，
debug_zval_dump()不递归展开，看不到子结构的引用关系。
真正影响内存的是：是否触发 COW 分离、是否进入 interned string 池、是否复用已分配的 zend_array bucket 数组。
大数组和大字符串的内存差异到底在哪
同样 1MB 数据，str_repeat('x', 1024*1024) 和 array_fill(0, 262144, 'x')（256K 元素）内存占用能差 3–4 倍。根本原因在底层存储模型不同。
关键参数差异：
- 字符串是连续内存块，开销小，只有长度 + 缓冲区；
- 数组默认按 2 的幂次预分配 bucket（如 262144 元素会分配 524288 个 bucket），每个 bucket 是 32 字节（64 位系统），光这部分就吃掉 16MB；
- 数组键名如果是字符串，还会额外触发 hash 计算和 key 的 interned 存储；
-
array_values()或array_merge()重建数组会强制重新分配 bucket，可能比原数组更省或更费，取决于原始填充率。
所以别只看元素数量，先用 count($arr) 和 sizeof($arr)（同义）确认大小，再结合 memory_get_usage() 差值判断是否真需要优化。
什么时候该怀疑内存不是变量本身的问题
如果你发现变量看起来不大，但内存涨得离谱，大概率是间接引用或资源泄漏在捣鬼。
典型场景：
- PDOStatement 对象执行后没
closeCursor()，结果集还挂在内存里； - 闭包绑定了大对象（
use ($bigArray)），即使函数执行完，只要闭包存在，$bigArray就不会释放； - 静态属性或 global 数组不断
[] = $newItem，形成隐式累积； - 开启了
xdebug.mode=debug，Xdebug 会深度追踪所有变量，内存用量翻倍甚至更多，关掉立刻回落。
最简单的验证方式：在疑似代码段前后各调一次 memory_get_usage(true)（获取真实分配量），如果差值远大于预期，说明有未察觉的资源绑定或扩展干预。
复杂点在于，PHP 的内存管理是分层的：Zend 引擎层、扩展层、glibc malloc 层，你看到的“占用”可能是某一层的预留，未必立刻返还给系统。别盯着数字绝对值，盯住增长趋势和释放时机更靠谱。
