用 memory_get_usage() 定位内存异常增长点：在中间件、控制器、循环等关键位置打点，结合 memory_get_peak_usage() 对比，避免 blade 中调用；配合 debug_zval_dump() 查引用计数、xdebug trace 分析调用链、php-meminfo 查存活对象分布。
用 memory_get_usage() 定位内存异常增长点
在 Laravel 中，内存泄漏往往不是全局性的，而是集中在某个请求生命周期内持续增长。最直接的方式是在关键位置插入 memory_get_usage() 打点，观察不同阶段的内存变化。
常见误判点：只看峰值，忽略「未释放但可回收」的对象（如闭包引用、静态属性缓存、事件监听器未解绑）。建议配合 memory_get_peak_usage() 对比使用。
- 在中间件开头/结尾、控制器方法前后、循环体内外各打一次点
- 避免在 Blade 模板中调用，因视图渲染可能触发延迟加载，干扰判断
- 注意 CLI 环境下
memory_get_usage(true)返回的是分配器实际申请的内存（含碎片），更反映真实压力
用 php --re 和 debug_zval_dump() 检查对象引用计数
Laravel 大量依赖容器绑定、事件分发和模型关系，容易因引用未断开导致 GC 无法回收。单纯看内存数字不够，得确认对象是否被意外持留。
debug_zval_dump() 能显示引用计数（refcount）和是否为循环引用（is_ref），但要注意它本身会增加一次引用，需减 1 后解读。
- 对疑似泄漏的模型实例（如
$user）执行debug_zval_dump($user) - 若
refcount> 2 且is_ref为bool(true)，大概率被全局变量、静态数组或闭包捕获 - 检查
app()->getBindings()和Event::getListeners()是否存在未清理的监听器
用 Xdebug + trace file 分析函数调用链与内存分配
当手动打点无法定位时，启用 Xdebug 的函数跟踪是关键。它能导出每行执行时的内存变化，精准定位哪次 new、collect() 或 with() 导致内存滞涨。
配置要点：在 php.ini 中启用 xdebug.mode=trace，并设置 xdebug.trace_format=1（便于 grep），同时开启 xdebug.collect_params=4 和 xdebug.collect_return=1。
- 在可疑请求前加
xdebug_start_trace()，结束后用xdebug_stop_trace() - 用
grep "memory=" trace.xt提取内存快照，按时间排序找突增段 - 重点排查
Illuminate\Database\Eloquent\Collection::load()、toArray()、json_encode()—— 这些操作常触发深层递归和重复克隆
用 php-meminfo 查看 PHP 内存中存活对象分布
php-meminfo 是一个轻量级扩展，能输出当前内存中所有活跃对象的类名、数量和总大小，比 get_declared_classes() 更贴近运行时真实状态。
安装后调用 meminfo_dump() 可生成 JSON，用 jq 快速分析：
php -r "print json_encode(meminfo_dump());" | jq '.classes | to_entries | sort_by(.value.count) | reverse | .[:10]'
- 若发现大量
Illuminate\Database\Eloquent\Model或stdClass实例，说明模型未及时unset()或集合未用->cursor()流式处理 - 若
Closure数量异常高，检查是否在循环中反复注册事件监听器或使用了未绑定上下文的匿名函数 - 注意
meminfo_dump()不包含已被标记为垃圾但尚未回收的对象，需配合gc_collect_cycles()主动触发回收再采样
真正棘手的泄漏往往藏在「合理但累积」的操作里：比如每次请求都往静态数组里 push() 查询结果、用 Cache::rememberForever() 存了未序列化的 Closure、或在 Job 中通过 $this->user 持有了整个认证实例。工具只是放大镜，关键还是理解 Laravel 生命周期里哪些引用是隐式持久的。
