LinkedList::drain_filter::drop中DropGuard的作用及为何不用catch_unwind？

我在查看DrainFilter的drop实现时，想确认它是否会移除所有剩余元素，结果注意到每个drop(item);调用周围都套了一个针对DrainFilter迭代器自身的DropGuard。我想知道这个Guard的作用是什么？除非drop(item);触发panic，否则我看不出它的用途。它是不是只是为了确保panic发生时仍能处理剩余元素？那为什么不用catch_unwind呢？

相关代码 #

impl<T, F> Drop for DrainFilter<'_, T, F>
where
    F: FnMut(&mut T) -> bool,
{
    fn drop(&mut self) {
        struct DropGuard<'r, 'a, T, F>(&'r mut DrainFilter<'a, T, F>)
        where
            F: FnMut(&mut T) -> bool;

        impl<'r, 'a, T, F> Drop for DropGuard<'r, 'a, T, F>
        where
            F: FnMut(&mut T) -> bool,
        {
            fn drop(&mut self) {
                self.0.for_each(drop);
            }
        }

        while let Some(item) = self.next() {
            let guard = DropGuard(self);
            drop(item);
            mem::forget(guard);
        }
    }
}

你猜的没错，这个DropGuard就是专门处理**drop(item)触发panic**的场景，核心是保证panic发生时，迭代器里剩余的元素依然能被正确清理，避免内存泄漏或数据残留。

具体逻辑拆解：

• 正常执行流程：每次取出元素后创建DropGuard，调用drop(item)完成元素清理后，用mem::forget(guard)手动跳过Guard的drop方法——因为当前元素已经处理完毕，剩余元素会在循环中继续处理，不需要Guard介入。
• panic触发时：如果drop(item)引发panic，程序会进入unwind流程，此时当前作用域内的局部变量会按逆序执行drop。DropGuard的drop方法会被自动调用，它会执行self.0.for_each(drop)，一次性处理迭代器中剩下的所有元素，确保资源被正确释放。

至于为什么不用catch_unwind，主要有这几点原因：

1. 兼容性问题：catch_unwind仅能捕获标准的panic unwind，在启用-C panic=abort编译选项的场景下，程序会直接终止，catch_unwind完全失效。而DropGuard依赖的RAII机制不受编译配置影响，可靠性更高。
2. RAII哲学契合：利用Drop trait实现资源清理是Rust的核心设计思想之一，这种方式更符合语言的惯用模式，逻辑清晰且无需额外的错误处理嵌套。
3. 简洁性与安全性：相比嵌套catch_unwind的写法，Guard的方式代码更简洁，且能保证无论panic是否发生，清理逻辑都会被执行，不会出现遗漏。

内容的提问来源于stack exchange，提问作者A.Z.