PHP SplObjectStorage 删除对象为什么要先判断存在：对象身份、detach 与遍历安全

用 SplObjectStorage 保存观察者、插件实例或临时资源时，删除动作最好不要直接写成“拿到对象就 detach()”。先用 contains() 确认对象仍在当前存储中，再执行删除，可以把“目标不存在”“拿错了同类对象”和“遍历过程中修改集合”这几种问题分开。这里的关键不是数组下标，而是对象身份。

先把对象身份和对象内容分开

SplObjectStorage 可以当对象集合使用，也可以给每个对象挂一段关联数据。两个内容完全相同的对象，仍然是两个不同的存储键：

attach($alice, ['channel' => 'email']);

var_dump($storage->contains($alice));     // true
var_dump($storage->contains($sameName));  // false

所以不能用“字段一样”推断目标一定存在。业务层如果只有用户 ID，应先通过自己的索引拿到存储中的那个实例，再交给 contains()；临时 new 出来的等价对象不能替代原实例。

删除前的 contains 检查解决什么问题

官方接口把 contains() 和 detach() 分成两个动作。推荐封装一个明确的删除方法，让调用方知道这次是“删除成功”还是“目标本来就不在”：

function removeSubscriber(SplObjectStorage $storage, Subscriber $subscriber): bool
{
    if (!$storage->contains($subscriber)) {
        return false;
    }

    $storage->detach($subscriber);
    return true;
}

$removed = removeSubscriber($storage, $alice);
var_dump($removed, $storage->count()); // true, 0
$removedAgain = removeSubscriber($storage, $alice);
var_dump($removedAgain);               // false

这个返回值很适合接入幂等的注销流程：第一次删除返回 true，重复请求返回 false，而不是把重复请求误报成新故障。若业务要求“重复删除必须报警”，就在返回 false 的分支记录对象类型、业务 ID 和请求 ID，不要把不存在的对象硬包装成成功。

遍历中直接 detach，风险在于边界不清

例如要清理已经失效的订阅者，直接在 foreach 中删除当前对象看起来很短，但集合的游标同时在移动，后续对象是否被跳过就不该靠猜。更稳妥的做法是第一遍只收集目标，第二遍统一删除：

$expired = [];
foreach ($storage as $subscriber) {
    $info = $storage->getInfo();
    if (($info['expires_at'] ?? 0) contains($subscriber)) {
        $storage->detach($subscriber);
    }
}

如果清理期间还有其他代码可能删除对象，第二遍的 contains() 就是最后一道边界检查。单线程并不代表调用链没有重入：回调、事件分发或异常恢复都可能让存储状态在两次操作之间发生变化。

对象集合改造时的检查清单

常见问题

两个属性完全相同的对象能互相 contains 吗？

不能。SplObjectStorage 关注对象身份；只有传入之前 attach 的那个实例，contains() 才会返回 true。

detach 一个不存在的对象会自动抛异常吗？

不要把业务行为建立在“删除不存在对象会怎样”的猜测上。用 contains() 先判断，并在代码中明确重复删除的返回和日志策略。

什么时候应该改用数组？

如果业务真正的键是用户 ID、字符串或整数，数组或普通映射更直观；只有需要以对象实例作为键，或需要给对象挂关联数据时，SplObjectStorage 才更贴合模型。

验收结果

• 同类同属性但不同实例的对象不会被误判为同一目标。
• 删除方法能区分首次移除与重复请求。
• 批量清理不在遍历游标前进时直接改集合。
• detach 后的资源释放和事件注销有独立的收尾逻辑。