laravel 6 服务容器本身不导致内存泄漏，问题在于误用：闭包捕获 $this、事件监听未解绑、单例内持静态资源、octane/swoole 下跨请求残留引用，需用 debug_zval_dump() 和 php-meminfo 定位并切断强引用。
Laravel 6 的服务容器本身不会导致内存泄漏，但你往里面塞的东西、怎么用它、以及请求生命周期外的残留引用，会。 容器的 $instances 数组只存单例（singleton() 绑定），普通 bind() 每次 make() 都新建对象，用完就丢——PHP GC 本该回收。问题出在“你以为它丢了，其实没丢”的地方。
为什么 app()->make() 后对象没被释放
常见于中间件、事件监听器、队列任务或 Swoole/Octane 环境中：对象被意外持留，GC 无法触发。典型表现是连续请求后 memory_get_usage() 持续上涨，且 gc_collect_cycles() 后无回落。
- 闭包捕获了
$this，而$this又持有容器或模型实例（比如在控制器里写Event::listen(..., function () use ($this) { ... })） - 事件监听器注册后未解绑（尤其在命令行或长驻进程中调用
Event::listen()） - 自定义单例类内部持有静态属性、全局数组或 PDO 连接（容器缓存了实例，但实例自己又钉住了其他资源）
- 在
register()中用了匿名函数绑定，如$this->app->bind('foo', function () { return new Foo(); })—— 这种写法绕过容器依赖注入，Foo构造函数里的依赖（如Logger）不会自动解析，容易手动 new 出未管理对象
singleton() 和 bind() 对内存的实际影响
别只看文档说“singleton 复用，bind 不复用”，得看复用的是什么、谁在用、用多久。
-
singleton(Service::class)：首次make()后实例进$instances，整个进程生命周期存在；若Service内部有静态缓存（如private static $cache = []），那这个数组会越积越大 -
bind(Service::class)：每次make()都 new，但若你在某处保存了返回值（如赋给类属性、塞进静态数组、传进未销毁的定时器回调），那它就变成“孤儿引用”，GC 不认识 - 错误示范：
$this->client = app()->make(ApiClient::class);放在控制器属性里 —— Laravel 6 的控制器是每次请求 new 的，看似安全；但若你启用了 Octane 或用了 Swoole，控制器实例可能被复用，$this->client就成了跨请求残留
如何验证并切断泄漏源头
不能只靠 memory_get_usage() 看数字，得确认对象是否真被释放。关键工具是 debug_zval_dump() 和 php-meminfo。
- 对疑似对象执行
debug_zval_dump($obj)，重点看refcount：若 >2 且is_ref为true，说明至少有两个强引用在持留它（常见于闭包 + 静态数组组合） - 运行
php-meminfo查当前存活对象分布，关注数量异常多的类（如App\Models\User、Illuminate\Database\Eloquent\Collection），它们往往不是容器问题，而是你Model::all()后没unset或没 chunk - 检查
app()->getBindings()和Event::getListeners()，看是否有不该存在的绑定或监听器（尤其在 Artisan 命令中动态注册后忘了清理） - 在中间件
handle()开头和结尾各打一次memory_get_usage()，若结尾没回落，说明中间件内创建的对象被外部持留（比如存到了static $buffer）
Octane/Swoole 下必须手动重置的点
Laravel 6 原生不支持长驻进程，但一旦套上 Octane 或 Swoole，容器实例就跨请求复用。沙箱模式（如 LaravelSwoole）默认只清 $bindings 和 $instances，不管这些：
-
Auth::user()返回的用户实例存在AuthManager的静态属性里，沙箱不碰它 - 手动调用过
config(['app.debug' => true])？这个修改会留在进程里，直到重启 - DB 连接若没配置连接池，PDO 实例会被容器 singleton 缓存，但底层 socket 可能已断，下次用时报错或卡住
- Redis 客户端（Predis）在协程下不安全，复用旧实例会导致连接污染，必须每次
go(function () { new Predis\Client(); })或换 co\Redis
真正难处理的从来不是容器本身，而是你把容器当黑盒，却在它外面悄悄建了一堆静态桥梁——那些桥不会随请求消失，只会越修越宽。
