di容器内存泄漏并非composer导致，而是因容器实例被长期持有、静态缓存未清理或循环引用未解绑所致；根本原因是php引用计数失效或gc漏检，常见于web环境中重复创建容器却未销毁旧实例。
Composer 本身不管理依赖注入容器的生命周期，所谓“第三方 DI 容器内存泄露”，实际是容器实例被长期持有、静态缓存未清理、或循环引用未解绑导致的 PHP 层面内存累积——不是 Composer 的 bug，但常在 composer install 后首次运行容器时暴露。
为什么 DI 容器会在 Composer 环境里“看起来像泄漏”
根本原因不是 Composer 加载了容器，而是你代码中对容器的使用方式触发了 PHP 引用计数失效或 GC 漏检：
- 在 Web 环境（如 PHP-FPM）中反复
require 'vendor/autoload.php'+new Container()，但没销毁旧实例，导致多个容器对象堆叠 - 容器内部用
static $instances = []缓存服务，且未设上限或清理策略，每次get()都往里塞新对象 - 服务定义里用了闭包（
fn() => new Service($this)），而闭包隐式持有了整个容器实例，形成 A→B→A 循环 - 某些老旧 DI 库（如早期 Pimple 版本）在
extend()时把原始值和回调一起存进静态数组，不释放就一直占内存
快速验证是不是容器真泄漏：三行命令定位
别猜，直接看内存里活着的容器对象数量和引用链：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 加一句
echo count(spl_object_ids(get_declared_classes()));在入口文件末尾，访问多次，数值持续上涨 → 说明类加载器或容器注册了新类/实例 - 运行
php -r "var_dump(gc_status());"，关注roots字段：如果它随请求增长，大概率存在未被 GC 清理的根节点（比如静态属性里的容器） - 用
xdebug_debug_zval('container')查看容器变量的 refcount 和 is_ref：若is_ref=1且refcount > 2，基本可判定有外部强引用未断开
常见 DI 库的典型陷阱与绕过写法
不同容器实现对内存管理的处理差异很大，不能一概而论：
-
Pimple 3.x：避免在extend()中返回匿名函数，改用工厂类；禁用$container->freeze()—— 它会让所有服务变成单例且无法 unset -
PHP-DI 7.x：不要在ContainerBuilder::addDefinitions()里传闭包，改用createFunction()显式声明依赖；启用useAutowiring(false)可减少反射扫描带来的临时对象 -
League\Container：慎用delegate()，委托链过长会堆积 Closure 实例；每次get()前先has()判断，避免无谓的解析开销 - 自研容器：检查
__destruct()是否被定义且能被触发（CLI 下没问题，FPM 下需确认 request shutdown 阶段是否执行）
真正有效的清理动作，不是重启进程
在不重启 PHP-FPM 的前提下，让容器内存回落的关键是主动切断引用，而非等 GC：
- 在请求结束前调用
$container->clear()（如果容器支持）或手动unset($container)，再补一句gc_collect_cycles() - 若容器通过静态方法提供单例（如
Container::getInstance()），必须配套Container::destroy()并清空静态属性，不能只 unset 局部变量 - 对高频创建的服务（如 Request、Response），改用
make()而非get()，避免被容器缓存 - CI/CD 测试中，每次
phpunit运行后加php -r "opcache_reset(); gc_collect_cycles();"，防止 opcache + GC 滞后叠加效应
最易被忽略的一点：DI 容器的“泄漏”往往和 composer dump-autoload -o 生成的 classmap 冲突。当 classmap 把某个服务类提前加载进内存，而容器又用反射去构建它，就会多出一份冗余对象副本——这种情况在启用了 --classmap-authoritative 时尤其明显，得关掉它单独测。
