PHP SplObjectStorage 遍历时移除当前对象为什么可能跳项

如果你在 foreach 遍历 SplObjectStorage 时直接移除当前对象，后面的对象可能没有按预期逐个处理，常见表现就是“跳过一项”。原因不是对象突然无法比较，而是遍历器和存储内容同时发生了变化：当前项被删除后，下一次推进可能跨过原本紧邻的对象。

更稳妥的做法是把“判断要不要删除”和“真正修改 storage”分成两个阶段。新代码优先使用 offsetUnset()；PHP 官方手册已标记 SplObjectStorage::detach() 自 PHP 8.5.0 起弃用，并建议使用 offsetUnset()。

官方文档：https://www.php.net/manual/en/class.splobjectstorage.php

SplObjectStorage 的遍历状态由什么组成

SplObjectStorage 既可以当作对象集合，也可以把对象映射到一份附加数据。它实现了迭代器相关接口，遍历时至少要关注四个动作：

• rewind() 把位置移到第一个存储元素；
• valid() 判断当前位置是否仍然有效；
• current() 取得当前位置的对象；
• next() 把迭代器推进到下一个对象。

foreach 会按照这套迭代状态读取对象。它不是先把 SplObjectStorage 自动变成一个普通数组副本，再对副本进行遍历。因此，循环体内调用删除方法时，当前存储的结构和迭代位置会互相影响。

为什么删除当前对象后可能跳过下一项

可以把存储暂时想成 O1 → O2 → O3 → O4。迭代器当前停在 O1 时删除它，存储会先变成 O2 → O3 → O4。随后循环还会继续推进迭代器，但“当前位置”已经不是删除前的那份序列，因而下一次读取可能直接落到 O3，让 O2 没有得到处理。

这也是为什么下面这种写法不适合做“遍历并删除”的通用模板：

attach(new Task('A', true));
$storage->attach(new Task('B', false));
$storage->attach(new Task('C', true));

foreach ($storage as $task) {
    if ($task->expired) {
        // 不要在同一个迭代器仍在推进时修改当前 storage。
        $storage->offsetUnset($task);
    }
}
?>

这里的问题不在 offsetUnset() 本身，而在删除动作发生在同一个遍历边界内。detach() 的旧写法也有同样的迭代风险，只是从 PHP 8.5 开始还会多出弃用提示。

第一种方式：先收集，再统一删除

如果删除条件只依赖当前对象或它携带的信息，最容易维护的方案是分两轮处理：第一轮只读 storage，第二轮再修改 storage。这样判断过程拥有稳定的遍历边界。

attach($job);
}

$toRemove = [];
foreach ($storage as $job) {
    if ($job->finished) {
        // 第一轮只收集对象，不改变迭代中的 storage。
        $toRemove[] = $job;
    }
}

foreach ($toRemove as $job) {
    // PHP 8.5+ 推荐用 offsetUnset() 替代已弃用的 detach()。
    $storage->offsetUnset($job);
}
?>

这种写法的关键是保存对象本身，而不是只保存一个整数下标。SplObjectStorage 的 key 是遍历位置，不是业务上的稳定身份；对象引用才能直接交给 offsetUnset()。

第二种方式：遍历副本，修改原 storage

如果业务希望在“读取每一项”的同时立即修改原集合，可以遍历一个副本，把原来的 $storage 留作写入目标。副本中的对象仍然是同一批对象引用，因此可以拿它们去取消原 storage 中的成员。

attach($job);
}

foreach (clone $storage as $job) {
    if ($job->finished) {
        // 读取的是副本，删除的是原 storage，两个迭代边界不冲突。
        $storage->offsetUnset($job);
    }
}
?>

这套方式适合删除条件需要立即执行副作用、或者原集合需要在一次循环中逐项更新的场景。代价是会创建一个 storage 副本；对象本身不会因为这次浅克隆而变成业务上的新对象，所以仍要避免在循环内同时修改对象属性并依赖复杂的嵌套遍历。

两种方式应该怎样选择

复查时别忽略这几个边界

1. 不要把 key 当成永久编号。遍历位置会随着增删变化，需要稳定业务标识时，把标识放进对象或附加信息中。
2. 嵌套遍历要分开迭代器。同一个 storage 被内层循环再次遍历时，外层位置可能受到干扰；必要时对要读取的那份 storage 使用副本。
3. 区分对象和附加信息。current() 返回当前对象，getInfo() 取得当前对象关联的信息，不能把二者混为一个数组下标。
4. 空集合先看 valid。手动调用 current() 前先确认 valid()，否则不要假定一定有对象。
5. 记录最终集合再做业务判断。如果删除动作还会触发通知、日志或回调，建议把这些副作用放在统一删除阶段，避免遍历中途改变更多状态。

常见问题

用 detach() 删除当前对象一定会跳过第二个对象吗？

不能把某个用户贡献示例中的具体输出当成所有版本、所有操作组合的稳定保证。可以确定的是：遍历期间修改同一个 SplObjectStorage 会让迭代边界变得脆弱，因此不应依赖“刚好不会跳项”的结果。新代码应采用两阶段删除或副本遍历。

offsetUnset() 和 detach() 的目的有什么区别？

二者都是从存储中移除指定对象；当前 PHP 官方手册将 detach() 标记为 PHP 8.5.0 起弃用，并建议用 offsetUnset()。迁移时保持对象引用和删除时机不变即可。

只想遍历而不删除，是否还要 clone？

单层只读遍历通常不需要。只有当回调内部可能再次遍历同一个 storage，或者当前循环会改变原集合时，才应考虑使用副本或先收集结果。

小结

SplObjectStorage 的跳项现象，本质上是“正在推进的迭代器”和“被修改的存储”发生了耦合。把判断与删除拆开，或者让读取发生在副本上，再用 offsetUnset() 修改原集合，就能把这类隐蔽问题变成清晰的两阶段流程。

参考资料

• https://www.php.net/manual/en/class.splobjectstorage.php
• https://www.php.net/manual/en/splobjectstorage.detach.php
• https://www.php.net/manual/en/splobjectstorage.current.php
• https://www.php.net/manual/en/splobjectstorage.next.php
• https://www.php.net/manual/en/splobjectstorage.valid.php