memory_get_usage()返回当前脚本已分配给PHP的活跃内存字节数，不包含已标记可回收但未释放的内存；加true参数才返回系统实际申请的内存块大小。
memory_get_usage 返回的是什么值
memory_get_usage 返回当前脚本已分配给 PHP 的内存字节数，不是操作系统看到的总 RSS，也不是峰值，只是 Zend 内存管理器当前“认为自己正在用”的量。它默认不包含未释放但已标记为可回收的内存（比如刚 unset 的变量，可能还滞留在内存池里）。
常见误解是以为它能反映真实物理内存占用——其实不能。如果你在 CLI 下跑脚本并用 ps 或 top 看到 15MB，而 memory_get_usage() 只返回 2MB，这完全正常。
- 加
true参数（即memory_get_usage(true)）才获取内存管理器向系统实际申请的内存块大小（通常对齐到 256KB 或更大页） - 不加参数时返回的是“当前活跃使用量”，更贴近你代码中变量实际占的空间
- 这个值在 GC 运行前后可能突变，尤其处理大数组或对象后记得手动调用
gc_collect_cycles()再测
监控内存增长要避开自动 GC 干扰
PHP 7.3+ 默认启用 Zend GC，但它不会立刻回收循环引用，导致 memory_get_usage() 在短时间内持续上涨，让人误判泄漏。直接在循环里打点测值，很可能看到“阶梯式上升”，其实是 GC 还没触发。
- 在关键节点后主动调用
gc_collect_cycles()，再立刻调用memory_get_usage()，结果更稳定 - 避免在函数内联、匿名函数闭包密集处高频采样——这些结构容易产生隐式引用，干扰 GC 判定
- CLI 模式下可通过
ini_set('zend_gc_disable', 1)临时关掉 GC 来做对比测试，但别在线上这么干
如何安全地在 Web 请求中记录内存峰值
Web 场景下，memory_get_peak_usage() 比 memory_get_usage() 更有用，因为它记录从请求开始到当前的最高水位。但要注意：它只在当前请求生命周期内有效，不能跨请求累计。
立即学习“PHP免费学习笔记（深入）”；
- 在脚本开头记录初始值：
$start = memory_get_usage()；结尾用memory_get_peak_usage()获取全程峰值 - 不要依赖
register_shutdown_function()里的memory_get_usage()值——关机函数执行时内存可能已被部分释放，数值偏低 - 如果用了 OPcache，注意
opcache.memory_consumption是独立于脚本内存的，memory_get_usage()完全不包含它 - 日志中建议同时记录
memory_get_peak_usage(true)，便于和系统级监控对齐
为什么 echo memory_get_usage() 后数值反而变大
看似奇怪，但很常见：当你用 echo 或 var_dump() 输出 memory_get_usage() 结果时，字符串拼接、格式化、输出缓冲区写入都会额外申请内存。尤其是开启 output_buffering 时，整个响应体先存在内存里。
- 测试时尽量避免在采样点附近做任何输出操作
- 如需记录，改用
error_log($val, 4)（直接写到 SAPI 错误日志）或写入文件，比 echo 更轻量 - 用 Xdebug 的
xdebug_memory_usage()替代原生函数，它在底层 hook 更干净，受干扰小
mbstring.func_overload 是否开启。没有统一阈值，只能结合调用栈和对象图分析。 
