必须用 memory_get_usage(true) 才能真实反映内存泄漏，因默认参数仅显示 Zend 内存池分配量，而 true 返回 malloc 实际申请页大小，可绕过缓存假象暴露 RSS 持续上涨问题。
直接用 memory_get_usage(true)，别用默认参数——否则你看到的不是真实内存增长，而是 Zend 内存池里的缓存假象。
为什么必须加 true 参数
PHP 默认调用 memory_get_usage() 返回的是 Zend 内存管理器当前分配的字节数，它不等于向操作系统申请的实际内存。大量小对象反复分配/释放后，Zend 会把空闲块留在池里复用，导致 memory_get_usage() 看似稳定，但 RSS（常驻内存）持续上涨。加 true 后返回的是 malloc 实际申请的页大小，能绕过内存池干扰，暴露真实泄漏。
- 不加
true：适合看脚本“当前用了多少内存”，但无法判断是否真泄漏 - 加
true：适合排查“每次请求是否多占了系统内存”，是线上定位泄漏的唯一可靠起点 - CLI 模式下跑 50 轮
php script.php，每轮记录memory_get_usage(true)差值；若稳定 +6KB～12KB，基本锁定泄漏模块
在哪几个位置埋点最有效
别全代码铺开打点，重点盯住三类高危操作：数据加载、循环构造、对象持有。每个点都用 error_log() 写独立日志文件，避免和业务日志混杂。
- 控制器入口处：
error_log('start: ' . memory_get_usage(true), 3, '/tmp/mem.log'); -
Db::table()->select()或Db::query()执行后立刻记录——ThinkPHP 的Collection对象极易滞留 - 大数组生成或 JSON 解析后（如
$data = json_decode($json, true)），马上打点 - 循环体末尾（尤其是
foreach或for），确认是否每轮都在涨
unset() 不等于释放，这些情况它没用
显式 unset() 只能解除变量名绑定，对内存释放无实质帮助，除非引用计数归零。以下场景 unset() 是无效操作：
立即学习“PHP免费学习笔记（深入）”；
- 对象被闭包
use捕获，且闭包本身被静态变量或全局数组持有（如$GLOBALS['hooks'][] = function() use ($obj) { ... };） - 查询结果存进
static $cache或Container::getInstance()->invokeFunction()，闭包隐式延长生命周期 -
Collection对象未转成数组就直接赋值给类属性：$this->items = Db::table('x')->select();，unset($this->items)不触发 GC - 资源句柄（如 cURL handle、PDOStatement）没调
curl_close()或$stmt->closeCursor()，仅unset()不释放底层内存
对比 memory_get_usage(true) 和 memory_get_peak_usage(true)
前者告诉你“此刻占了多少”，后者告诉你“这次请求最多占过多少”。两者差值大，说明有临时高峰但已回落；两者同步持续上涨，才是典型泄漏。
- 单次请求内，如果
memory_get_usage(true)在结尾仍比开头高 2MB+，且memory_get_peak_usage(true)更高，说明中间有大对象没释放 - FPM 模式下，关注单次请求内的变化；CLI 模式下，关注多轮执行后的累计偏差
- 别只看峰值——有些泄漏是缓慢累积的，
peak可能不变，但usage每轮微涨，这才是最危险的信号
真正难处理的不是大数组撑爆内存，而是那些看似无害的闭包引用、静态缓存、ORM 查询构建器残留——它们不会立刻报错，但会让进程 RSS 每天涨几百 MB，直到某次请求突然触发 Allowed memory size exhausted。埋点要早，验证要狠，别等 OOM 才动手。
