回答。

问题的历史

RAII（资源获取即初始化）是源自C++的一种习语，其核心是资源的生存期严格与栈中对象的生存期相关。在Rust中，这一概念构成了资源拥有权和释放系统的基础，使得我们不再依赖传统的垃圾收集器（GC）。

问题

许多语言通过垃圾收集器来管理内存和资源，垃圾收集器周期性地“清理”不需要的对象。这种策略会导致延迟并且不能保证立即释放外部资源（如文件、套接字等）。在低级和系统编程中，这种情况是不可接受的：需要对资源的管理具有精确性和确定性。

解决方案

在Rust中，每个对象拥有其资源并在销毁位置（超出作用域时）严格释放该资源，通过调用Drop（类似于析构函数）。这意味着资源会立即释放，所有隐式释放的错误被降至最低。Rust的类型和拥有权系统几乎在编译阶段就可以防止内存泄漏和双重释放。

代码示例：

struct FileWrapper {
    file: std::fs::File,
}

impl Drop for FileWrapper {
    fn drop(&mut self) {
        println!("FileWrapper关闭文件! （作用域退出）");
    }
}

fn main() {
    let _fw = FileWrapper { file: std::fs::File::create("test.txt").unwrap() };
    // 退出main时，会保证调用drop
}

关键特点：

RAII保证资源在超出作用域时会被同步释放。
不需要像在C或C++中那样手动调用释放，也没有来自GC的“惊喜”。
适用于所有资源，不仅仅是内存（锁、描述符、文件等）。

陷阱问题。

对于早期已被移动（moved）的值，是否会调用Drop？

不会，移动值后，仅为新所有者调用Drop，旧对象被视为“空”，不会触发Drop.

let file1 = FileWrapper {...};
let file2 = file1; // file1移动
// Drop只会调用一次——为file2

在作用域中，如果发生panic!或unwrap()，是否会阻止drop的调用？

不会，panic或错误退出不会取消析构函数的调用——Drop一定会为所有超出作用域的对象调用.

如果引用拥有对象，引用生命周期结束时会调用drop吗？

不会，drop仅为对象的所有者调用，引用不拥有资源。对于堆资源，需要智能指针.

常见错误和反模式

期待Drop会对引用或非拥有者生效——这将导致资源泄漏。
在不理解共享拥有权的情况下，将资源移动到Rc/Arc中——对象不会释放，只要还有一个Rc存在。

生活中的例子

负面案例

开发者通过引用将文件描述符传递给写入函数。程序结束后，文件被锁住，因为drop没有被调用（没有所有者，用的是引用）。

优点：

简单实现原型

缺点：

文件锁未释放
描述符泄漏

正面案例

资源所有权始终通过实现了Drop的结构体传递。所有打开的文件、连接或锁在作用域结束或panic时会自动释放。即使在复杂项目中也可以安全而轻松地管理资源。