splobjectstorage 不自动释放对象内存，因强引用持续存在；须显式 detach 或 unset，配合 spl_object_id 和 memory_get_usage 定位泄漏，避免静态存储累积，并确认 gc 无法回收此类引用。
PHP 8.1 中 SplObjectStorage 保存对象后，对象销毁但内存未释放，本质不是 SplObjectStorage 自身“不释放”，而是你仍持有对该对象的引用——只要它还在 SplObjectStorage 实例中（哪怕对象逻辑上已“不用”），PHP 就不会回收其内存。
确认对象是否真被移除
SplObjectStorage 不会自动清理已销毁的对象；它只在你显式调用 detach() 或 offsetUnset() 时才断开引用。对象即使超出作用域、被 unset 或离开函数，只要还留在 SplObjectStorage 里，就持续被强引用。
- 检查是否遗漏了
$storage->detach($obj)或unset($storage[$obj]) - 避免用
foreach ($storage as $obj)后直接丢弃循环变量——这不等于从 storage 移除对象 - 调用
$storage->count()打印数量，对比预期生命周期，确认是否越积越多
用 spl_object_id 辅助追踪对象存活状态
spl_object_id() 返回对象唯一整数 ID（PHP 7.2+ 支持），比 spl_object_hash() 更轻量、更稳定，适合日志埋点：
- 在
attach前记录：$id = spl_object_id($obj); echo "attached: {$id}\n"; - 在预期销毁点（如请求结束前）再次检查该 ID 是否仍在 storage 中：
if ($storage->contains($obj)) { ... } - 配合
memory_get_usage()在关键节点打点，观察 ID 持续存在是否对应内存增长
警惕静态或全局存储导致的隐式长生命周期
若 SplObjectStorage 实例本身被赋值给 static 属性、全局变量或常驻协程中的属性（如 Swoole Worker 内），它将贯穿整个进程生命周期，所有 attach 过的对象都会累积不释放。
- 检查声明位置：是否写在类 static 属性、
global $storage或协程上下文单例中？ - 协程场景下，优先使用 per-request 或 per-task 的局部
SplObjectStorage实例，而非跨协程共享 - 必须长期持有时，设计明确的清理入口（如
clearAll()或定时removeAllExcept()）
验证 GC 是否介入及手动触发
PHP 的循环引用 GC 默认启用，但仅对 zval 级别闭环生效；而 SplObjectStorage 是强引用容器，不构成 GC 可识别的“环”。因此不能依赖 GC 自动回收。
- 不要指望
gc_collect_cycles()解决此问题——它对SplObjectStorage中的对象无效 - 可临时加
gc_disable()+ 手动detach测试：若禁用 GC 后内存仍不涨，说明泄漏源就是未 detach - 上线环境务必保持
gc_enabled开启，仅用它辅助排查，而非修复手段
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
