PHP无法直接获取单个变量内存占用，需结合memory_get_usage(true)测差值、xdebug_debug_zval()查引用、避免热路径用serialize()，重点监控生命周期与复制行为。
怎么知道某个变量占了多少内存
PHP 没有直接暴露变量内存占用的函数，memory_get_usage() 是全局的，没法单独看一个变量。想粗略估算，得靠 serialize() + strlen()，但这只反映序列化后的字节长度，不是真实内存开销；更准一点的做法是用 debug_zval_dump() 看引用计数和是否为引用，但注意它输出的是调试信息，不能直接用于性能监控。
- 真实内存占用受 zval 结构、类型、是否共享（如 interned string）、是否被引用影响，无法单靠一个函数精确读取
-
debug_zval_dump($var)会多一次引用（输出时复制），看到的 refcount 比实际高 1，要手动减去 - 大数组或对象嵌套深时，
serialize()本身开销不小，别在热路径里用
用 xdebug_debug_zval() 查引用和生命周期问题
xdebug_debug_zval() 比原生 debug_zval_dump() 更可靠，能显示是否为“is_ref”、refcount、zval 类型，对排查循环引用、意外内存不释放特别有用。但它依赖 Xdebug 扩展，且只在开发环境开启——线上禁用。
- 没装 Xdebug 时调用会报 Fatal error: Uncaught Error: Call to undefined function xdebug_debug_zval()
- 输出中的
refcount=2不代表还有两个变量指向它，而是当前作用域内该 zval 被引用的次数（含临时拷贝） - 对象属性如果是引用赋值（
&$obj->prop），refcount 会异常升高，容易误判为内存泄漏
大数组/对象初始化阶段就测内存波动
真正影响性能的不是变量“存在”，而是创建、复制、序列化、GC 扫描时的瞬时峰值。所以要在关键节点前后用 memory_get_usage(true)（带 true 表示获取分配器分配的总内存，更准）抓差值。
- 别用
memory_get_usage()默认参数，它返回的是脚本当前使用的内存，不含未释放的碎片，波动干扰大 - 测试前先调用
gc_collect_cycles()，避免上一轮残留影响读数 - 对
json_encode()或var_export()大变量的操作，本身就会触发大量临时 zval 分配，测出来的是操作开销，不是变量静态大小
什么时候该怀疑变量导致性能问题
变量本身几乎不会“慢”，出问题基本是因为：被反复序列化、作为参数深层递归传递、被 Closure 绑定后长期驻留、或在循环中不断追加却没 unset。尤其注意 $_SESSION、静态属性、全局数组这类生命周期长的容器。
立即学习“PHP免费学习笔记（深入）”；
-
$_SESSION['data'] = $huge_array;后没做unset($_SESSION['data'])，下次请求仍会反序列化整个结构 - 用
array_merge()在循环里拼大数组，每次调用都复制全部内容，O(n²) 时间复杂度 - 对象里存了
resource（如mysqli连接）或闭包，GC 无法回收，refcount 始终不归零
变量性能分析不是看单个值，而是看它在生命周期里被怎么用、在哪被复制、何时该放手。工具只是提示，关键还是代码里那几行赋值和销毁的时机。
