RAII的核心是资源与对象生命周期严格绑定，智能指针仅解决堆内存，文件句柄、socket等非内存资源须封装为独立RAII类，析构函数必须noexcept且不可抛异常。
RAII 不是“用了智能指针就万事大吉”
很多开发者以为只要把 new 换成 std::make_unique 就完成了 RAII，但实际中泄漏仍频繁发生。根本原因在于：RAII 的核心是「资源生命周期与对象生命周期严格绑定」
常见错误现象：fclose(fp) 被遗漏；pthread_mutex_unlock() 在异常路径下未执行；glDeleteBuffers() 在 early-return 时跳过。
- 所有非 trivial 资源（即需显式释放的）都应包装为独立的 RAII 类，而非裸调用 API
- 禁止在构造函数里做可能抛异常的资源获取操作（如打开文件失败），否则析构函数不会被调用 → 改用工厂函数 +
std::optional或返回std::expected（C++23） - 避免在 RAII 类中存储裸指针或引用——它们不参与所有权管理，极易悬空
std::unique_ptr 和 std::shared_ptr 的选用陷阱
std::shared_ptr 带引用计数开销，且容易引发循环引用；std::unique_ptr 是零成本抽象，但默认只管理单个对象。二者误用是内存泄漏和性能问题的温床。
典型误用场景：用 std::shared_ptr 管理本该独占的资源（如一个临时 socket 连接），或在不需要共享语义的地方引入 std::enable_shared_from_this。
- 优先用
std::unique_ptr：资源归属明确、无共享需求、性能敏感（如高频创建销毁的 buffer） - 仅当确实需要多所有者语义时才用
std::shared_ptr，并配合std::weak_ptr打破循环 - 对数组要用
std::unique_ptr，不能用std::unique_ptr—— 否则delete而非delete[]，UB 导致泄漏+崩溃 - 自定义 deleter 必须是无状态的（或用 lambda 捕获空）；有状态 deleter 会增大
std::unique_ptr对象体积，且无法通过std::move安全转移
std::lock_guard 和 std::unique_lock 的关键区别
很多人把 std::lock_guard 当作“自动 unlock 工具”，却在需要延迟加锁、条件等待或手动 transfer 锁时强行硬套，结果导致死锁或未定义行为。
错误示例：std::lock_guard 构造后立刻 unlock() —— 编译不过；或试图把它从函数返回 —— 移动语义不支持。
-
std::lock_guard：仅用于作用域内简单加锁/自动释放，不可复制、不可移动、不可延迟加锁 -
std::unique_lock：支持延迟构造、try_lock()、unlock()、release()、与std::condition_variable配合，但体积更大、开销略高 - 永远不要用
std::scoped_lock管理单个 mutex —— 它专为多 mutex 死锁安全设计，单个时反而冗余 - 跨作用域传递锁？别传锁对象本身，改用 RAII 包装器控制访问权限（如
LockedResource）
自定义 RAII 类必须实现 noexcept 析构
C++ 标准规定：若析构函数抛异常，程序直接调用 std::terminate()。而 RAII 类的析构函数恰恰是释放资源的最后一道防线，一旦在这里抛异常（比如 close 失败返回 -1 且你写了 throw），整个程序就崩了——连泄漏都来不及观察。
真实案例：某网络库在析构中调用 shutdown(fd, SHUT_RDWR) 后检查返回值，错误地 throw 了 std::system_error，导致服务进程静默退出。
- 所有 RAII 类的析构函数必须声明为
noexcept（C++11 起默认隐式为noexcept(true)，但显式写上更安全） - 资源释放失败（如
close()返回 -1）只能记录日志或调用std::abort()（极端情况），绝不可 throw - 若资源释放逻辑复杂且可能失败，应把“释放动作”拆到独立方法中（可抛异常），而析构函数只做
if (owned_) release_noexcept(); - 注意：
std::vector、std::string等标准容器的析构函数也是noexcept，它们内部释放内存不会抛异常 —— 你的 RAII 类要保持同等级契约
class FileHandle {
int fd_ = -1;
public:
explicit FileHandle(const char* path) : fd_(open(path, O_RDONLY)) {
if (fd_ == -1) throw std::system_error{errno, std::generic_category()};
}
~FileHandle() noexcept { // ← 关键：noexcept
if (fd_ != -1) ::close(fd_); // 忽略 close 返回值；失败也不 throw
}
FileHandle(const FileHandle&) = delete;
FileHandle& operator=(const FileHandle&) = delete;
FileHandle(FileHandle&& other) noexcept : fd_(other.fd_) { other.fd_ = -1; }
FileHandle& operator=(FileHandle&& other) noexcept {
if (this != &other) {
if (fd_ != -1) ::close(fd_);
fd_ = other.fd_;
other.fd_ = -1;
}
return *this;
}
};C++ RAII 的难点不在语法，而在对“资源边界”的持续警惕——每次新增一个 malloc、fopen、cudaMalloc，都意味着你亲手撕开一个可能泄漏的口子，必须立刻用 RAII 缝上。最常被忽略的，是那些没有标准智能指针覆盖的资源类型，以及析构函数里那一行看似无害的 return -1 检查。
