C++ unique_ptr：独占所有权、移动与自定义删除器
08 unique_ptr 把独占所有权写进类型里
在一个使用了现代 C++ 的代码库里，如果有人让你判断某个函数返回的堆对象应该由谁来释放，你不需要去翻文档、找注释、或者追溯该函数的实现来确认它内部有没有把释放责任转移给调用方——你只需要看它的返回类型。如果它返回的是 std::unique_ptr<Widget>，答案就直接写在类型签名上：调用方获得的是这个 Widget 对象的唯一所有权，销毁该对象的责任也随之转移到了调用方手中。同样地，如果某个函数参数的类型是 std::unique_ptr<Widget>，它就在声明上告诉你"我会接管这个对象，调用之后你不再持有它"。
裸指针的返回类型 Widget* 在面对同一个问题时给出的答案是沉默的——你不知道 Widget* CreateWidget() 返回的指针是需要你自己 delete，还是指向某个内部缓存不需要释放，还是指向了一份由 shared_ptr 共享管理的对象。类型 Widget* 上没有任何比特记录着这个信息，它只记录了地址。std::unique_ptr<Widget> 的不同恰好在于：它把"这个对象归我管，我是唯一的管理者，我销毁时它跟着一起销毁"的整套独占所有权契约，以编译器可检查的方式编码进了类型。前七章从存储位置、生命周期线、new/delete 四步机制到 RAII 框架，为这种编码方式铺设了完整的机制基础——而本章要展开的是，这些机制在"独占所有权"这一最常用的资源管理场景下是如何集中兑现的。
一根所有权线，且只存在一根
当你写下 auto p = std::make_unique<Widget>("demo") 时，内存中发生了三件事。第一，make_unique 在自由存储区分配了足以容纳一个 Widget 的内存。第二，它在那块内存上执行了 Widget 的构造函数（传入参数 "demo"）。第三，它把指向这块内存的裸指针封装进了一个 unique_ptr<Widget> 对象里——这一步之后，p 就是 Widget 对象的唯一法定管理者了。p 本身是一个自动对象，放在栈帧上，内部只存了一个裸指针和一个删除器（在默认删除器场景下，标准库实现用空基类优化使 unique_ptr 的大小与裸指针完全相同——它没有额外空间开销）。堆上的 Widget 和栈上的 p 之间连着一根所有权线，这根线在 p 的有效期内不可被复制——但可以被移动——而且在 p 的析构函数触发的那个瞬间，这根线会把销毁指令精确地传导到堆上的 Widget。
把这根所有权线和裸指针对比，才能看出 unique_ptr 加了一层什么。int* p = new int(42) 之后，p 和那个堆上的 int 之间存在一根线——但那是程序员脑中的线，不是类型系统里的线。写 int* q = p; 的人在那一毫秒也拥有了"某种访问关系"——可能是借用，可能是共享，可能是接管——但 int* 这个类型不记录、不区分、不约束这三种关系中的任何一种。unique_ptr 做了两件和裸指针完全不同的事：第一，在它身上只有一根线——独占性被写在类型里，编译器对其他任何试图建立第二根线的操作一律拒绝；第二，这根线在它的析构函数里牵连着一个确定性的销毁动作——当 p 离开作用域时，delete 不是由你决定的，是由语言规则在 unique_ptr 的析构函数里替你执行的。
零额外空间开销这一点值得单独展开，因为它是 unique_ptr 作为"默认智能指针"的关键工程论据之一。在默认删除器场景下，sizeof(std::unique_ptr<T>) == sizeof(T*)——标准库通过空基类优化（Empty Base Optimization）将无状态的默认删除器 std::default_delete<T> 压缩为零字节，unique_ptr 对象的内存布局就是一个裸指针加上一个零字节的删除器基类子对象，最终大小等同于一个裸指针。这意味着用 unique_ptr 替代裸指针在绝大部分场景下是真正的零空间代价——你获得的是编译器强制执行的所有权不变量，付出的只是在移动构造和析构时多执行的几行确定性代码，而这些代码在没有 unique_ptr 时你本来也应该手写，且很容易写错或写漏。零空间开销让 unique_ptr 可以毫无心理负担地作为堆对象管理的默认选择——不存在"为了类型安全而牺牲了内存"的权衡，因为根本没有牺牲。
这种独占性最容易被破坏的方式是拷贝——而 unique_ptr 对它的防御是编译期的。如果你写下 auto p2 = p1;（其中 p1 和 p2 都是 unique_ptr<Widget>），编译器不会执行任何运行时代码来尝试"共享地复制一个所有权"——它直接拒绝编译，因为 unique_ptr 的拷贝构造函数被标记为 = delete。这和第 6 章讨论的 = delete 在特殊成员函数上的应用是一致的逻辑：把"不应该被允许的操作"从人脑中的记忆点变成编译期的硬拒绝。如果拷贝被允许，则会有两个 unique_ptr 各自怀着一根独占所有权线指向同一个 Widget——p1 析构时释放 Widget，p2 析构时再次对已经释放的地址执行 delete，双重释放的 UB 完整重现，而且和第 6 章中 Buffer 的例子共享同一个根因：两个管理者在类型系统层面各自拥有不可见对方的分管权，而两个分管权在析构时间点上必然冲突。
这整条防线还有一个容易被过度推导的地方需要精确限界：禁止拷贝的是 unique_ptr 这个管理者，不是 Widget 本身。你的代码完全可以创建 Widget 的两个独立副本，分别用两个 unique_ptr 各自管理——只要每个 unique_ptr 管着自己的那个独立 Widget 对象，就不会有任何冲突。"unique_ptr 管理着 Widget 因而 Widget 也不可拷贝"这种推理是不成立的——unique_ptr 只管着自己线头上的那一个 Widget，管不到 Widget 的克隆操作。Widget 能不能拷贝取决于 Widget 自身有没有拷贝构造函数，这个决策和 unique_ptr 的禁止拷贝互不干扰。
一个持有 unique_ptr 成员的类也继承了这种移动语义——如果一个类包含 std::unique_ptr<T> 成员，那么编译器自动生成的拷贝构造函数和拷贝赋值运算符会被隐式删除（因为 unique_ptr 成员本身不可拷贝），但移动构造函数和移动赋值运算符仍然可用（如果其他成员没有阻止它们）。这种传染性恰好是设计意图的一部分：如果类的一个成员是独占资源，那么包含这个成员的类本身也自动变成了独占语义——不能被随意拷贝，只能通过移动转移所有权。这与第 6 章讨论的 Rule of Zero 完全一致：只要所有成员都是 RAII 类型，编译器生成的特殊成员函数就自动完成了正确的资源管理行为，不需要你手写任何析构、拷贝或移动函数。
在实际项目中，unique_ptr 的独占所有权还有一个常被低估的额外收益：容器的遍历、重新分配、排序等操作不会意外触发重复释放。如果你往 std::vector<unique_ptr<Widget>> 里 push_back 元素后做了一次 resize 清空，vector 析构时会逐一析构内部的 unique_ptr，每个 unique_ptr 释放自己管着的那一个 Widget——不需要手动遍历容器先 delete 再清空。而如果你用的是 std::vector<Widget*>（裸指针），每次在容器销毁前忘记遍历清理就是一批 Widget 的批量泄漏。从裸指针容器到 unique_ptr 容器，正确地改变了"容器拥有元素的所有权"这个事实在类型系统上的编码状态——在裸指针版本中这是空的，在 unique_ptr 版本中这是被语言强制执行的第 0 行代码。
移动是所有权在调用链上的定向流转
unique_ptr 不能拷贝，但可以移动——这条设计不是在试图"禁止"和"允许"之间找一个折中，而是对不同所有权的操作做了明确的语义区分。拷贝意味着"你要一份副本，而我把原版也留着"——这在独占所有权的框架下根本不是一个合法的语义，因为独占意味着不存在"两个人同时拥有"的状态。移动意味着"我把所有权给你，我退出"——这在独占所有权的框架下恰好是最自然的流转方式：所有权的持有者可以从一个变量变成另一个变量，从工厂函数变成调用方，从调用方变成内部消费者——只要在任何时刻都只有一个变量在持有，独占性就没有被打破。
auto p1 = std::make_unique<Widget>("source");
auto p2 = std::move(p1); // 所有权从 p1 流转到 p2// p1 现在是 nullptr，p2 是唯一拥有者
这个移动操作在运行时由移动构造函数完成，它的实现可以压缩到三行：把源对象的内部裸指针值赋给目标对象、把源对象的内部裸指针清空为 nullptr、把删除器从源对象转移到目标对象（无状态删除器受益于空基类优化，此步骤被完全消除）。整个过程是零分配的——它没有触动堆分配器，没有触发任何可能失败的资源获取，也没有在中间插入任何可能被打断的操作窗口。移动构造完成后，p2 接过了这根所有权线，p1 被置空——p1 的析构在未来的某个作用域退出的时刻照常触发，但由于它内部的裸指针值是 nullptr，析构中的 delete nullptr 是无操作，安全无害。
关于移动后源对象的空状态，标准库对 unique_ptr 给了一条比一般 moved-from 对象更强的保证。std::string 在移动后是"有效但未指定"——你只知道它有效但不知道它的具体内容是什么。std::unique_ptr 在移动后做出了更精确的承诺：移动后源 unique_ptr 的内部指针一定等于 nullptr。这条更强的保证的直接收益是你可以把移动后的 unique_ptr 安全地重新赋值给它接管另一个对象（p1 = std::make_unique<Widget>("new")），或者使用 if (p1) 检查它是否还管着对象以获得精确的空判断。这和前面第 5 章讨论过的 moved-from 安全性准则完全一致——析构函数的确定性执行要求所有 moved-from 状态至少是析构安全的——unique_ptr 选择了最直接的实现：析构 nullptr 的 unique_ptr 等同于什么都不做。
移动赋值在接手新对象之前会先对自己原本持有的旧对象执行 delete——这件藏在实现细节里的事在业务代码中是完全透明的，但一旦你有过手写 RAII 类的经验（如第 6 章的 Buffer），你就会认出这恰好是移动赋值中"先释放旧资源再接管新资源"的标准顺序。p2 = std::move(p1); 会先析构 p2 原本管着的 Widget，然后才把 p1 的内部指针转移过来并将 p1 清空。如果跳过释放旧对象的步骤，旧 Widget 就会在没有任何指针引用它的情况下永远留在堆里——泄漏。对于只使用 make_unique 和移动的日常代码，这一步是隐式的、自动的、不需要人为干预的——unique_ptr 的设计者已经替你在移动赋值里实现好了。移动后的 unique_ptr 不仅可以安全析构，还可以通过 reset() 或移动赋值重新获得新的管理对象——一个 moved-from 状态的 unique_ptr 在类型系统中依然是一个有效、完整、可以重新使用的对象，这和裸指针在 delete 后变成悬空指针的状态是彻底不同的：裸指针在 delete 后继续持有旧地址值，任何时候的误用都是 UB；unique_ptr 在移动后被置为 nullptr，任何通过 nullptr 去访问对象的尝试都会在解引用时立刻触发可观测的段错误（而不是静默地操作已释放内存），这种 fail-fast 的行为在安全属性上是另一个维度的提升。
工厂模式是所有权流动最自然的载体。当一个函数签名是 std::unique_ptr<Widget> MakeWidget() 时，所有权从函数内部沿着返回值流向了调用方。在这个过程中，如果编译器成功应用了 RVO，连移动构造都不会被调用——Widget 直接在调用方的栈帧上被构造，unique_ptr 也随之在调用方的栈帧上被初始化。如果 RVO 不能适用（比如函数有多个 return 语句指向不同的对象），编译器自动插入一次移动构造，把函数内部 unique_ptr 的所有权干净地转移到调用方的 unique_ptr 上，函数内部的那个 unique_ptr 变成空，整个过程中没有一次裸指针暴露到调用方的可见代码区里。
所有权在 unique_ptr 的成员变量形式中还有一条隐式的传递链：当一个类用 unique_ptr 作为成员来管理子对象时，含该类对象的外层对象也自动获得了对子对象的正确析构——不需要在外层类的析构函数里手写 delete member_。更进一步地，外层的对象如果是按照 Rule of Zero 设计的（它的所有成员都是 RAII 类型），那么外层类连析构函数都不必定义——编译器生成的析构函数析构 unique_ptr 成员时，unique_ptr 自己的析构函数自动释放它管着的子对象。这条链从子对象传到成员 unique_ptr，从成员 unique_ptr 传到外层类，从外层类再传到任何以值或 unique_ptr 持有外层对象的上层——整条所有权链的释放逻辑从上到下逐层自动触发，任何一个节点都不需要写 delete。这种逐层自动化正是第 7 章 RAII 所描述的"构造获取、析构释放"在逐级嵌套的所有权结构上的自然展开，而 unique_ptr 扮演的是其中最底层、最常被使用的那一级动态对象管理节点。
为什么优先用 make_unique，而不是用 new 初始化 unique_ptr
std::make_unique<T>(args...) 在 C++14 中被加入标准库，从表面上看它只是省掉了你写 std::unique_ptr<T>(new T(args...)) 中的一次 new 拼写。但它的真实价值在于消灭了 new 返回的裸指针在传入 unique_ptr 构造函数之前的那一小段暴露窗口。
// 危险窗口：new 返回的裸指针在被 unique_ptr 接管之前// 如果两个 new 之间的参数求值序列中某个步骤抛出了异常// 已经分配的裸指针永远没有进入任何 RAII 管理结构 —— 泄漏foo(std::unique_ptr<Widget>(new Widget("a")),
std::unique_ptr<Widget>(new Widget("b")));
这个例子中的泄漏路径不是在逻辑上"可能发生"——它在一个函数调用的参数求值期间完全是可触发的事件。C++ 对函数参数的求值顺序在 C++17 之前是完全不指定的，即使在 C++17 之后也只是部分指定——两个 new 表达式之间、以及它们和 unique_ptr 构造函数之间的交错求值仍然可能在中间夹杂一个抛出异常的子表达式。一旦异常被抛出，已经由 new 返回来的裸指针就脱离了所有 RAII 的保护范围——它还没有被传进 unique_ptr 的构造函数，也永远不会有机会了。这个泄漏窗口在概念上和第 7 章中手工资源管理代码的多出口泄漏问题是同构的：在资源获取（new）和资源管理结构的建立（unique_ptr 构造）之间存在一条任何异常都可能穿透的间隙，而 make_unique 的解决方案也和 RAII 的核心思想一致——把获取和封装这两步合并成一个不可被外部中断的原子操作。
make_unique 把这个窗口降到了零。auto p = std::make_unique<Widget>(args...) 直接将参数包转发到函数内部，由函数内部的实现去调用 new 并在同一行代码中将返回的裸指针立即封装进 unique_ptr——没有任何调用方代码可以在中间插入一条可能抛异常的语句。分配、构造、封装三步在 make_unique 内部原子化地完成之后，才将完整的、已经被 RAII 包裹的 unique_ptr 返回给调用方。调用方从此不再在任何时间点接触到裸指针。
make_unique 还有两个经常被忽略的附加优势。第一，代码中的 std::make_unique<Widget>(args) 天然地确认了"这个 Widget 在创建之初就被 unique_ptr 管理"——阅读代码的人不需要去怀疑"这个 unique_ptr 会不会是从某个裸指针接管过来的、它凭什么有独占权"。第二，如果将来 Widget 的销毁方式需要从 delete 切换到自定义删除器，用 make_unique 创建的对象可以后续迁移到 unique_ptr 带有自定义删除器的版本，而用 new 创建的则需要逐个排查调用点来确定清理语义是否需要调整。
有少数场景不能用 make_unique：自定义删除器不在默认删除器的模式内，需要用 unique_ptr 的构造函数直接指定删除器类型——但自定义删除器的使用应当被限制在包装层内部，避免让不同删除器类型的 unique_ptr 在公共接口上交叉流动导致类型分歧；或者你接收到了一个已经由其他代码以裸指针形式交付给你的堆对象——比如来自 C 接口的返回指针——此时你也只能用 unique_ptr 的构造函数将其封装，封装完成后应立即通过移动或返回的方式将其纳入标准的 RAII 传递链路，不要再让裸指针在原调用点继续可见。在这两类场景之外，"我从零创建一个新对象并想用 unique_ptr 管它"的统一答案就是不附带任何 new 的 std::make_unique<T>(args)——它更短、更安全、更能清晰地向代码阅读者表达"此对象创建之初就处于独占管理之下"。
get、reset、release：三把不同钥匙，两把是单向的
三个成员函数中，get() 的方向是向外借出裸指针但所有权不离开 unique_ptr——方向是借用，所有权线原封不动。reset() 的方向是向里换一个管理的对象——方向是替换，但所有权线始终握在自己手里。release() 的方向是向外交出裸指针并彻底放弃管理——方向是交出，所有权从类型系统的保护区离开，进入裸指针的荒野。
get() 的使用场景在前七章讨论过的"借用"和"拥有"二分法中属于纯粹的借用操作。p.get() 返回的裸指针可以被传给任何只接收 T* 或 const T* 的函数，只要那些函数不尝试 delete 它。它的生命周期完全绑定在原始 unique_ptr 的有效期内——一旦 p 被移动、被 reset()、或离开作用域，从 p.get() 获得的所有裸指针全部悬空。get() 作为借用通道和 const T& 作为借用通道在语义上是同构的——区别只在 get() 可以传 nullptr（通过检查 p 对象本身即可判断），而 const T& 在语义上不接纳空值。当接口需要表达"可能没有对象"的借用语义时，T*（由 get() 提供）是比 const T& 更精确的选择。
reset() 是最安全的所有权变更入口，因为所有权全程不离开 unique_ptr 的内部管理域。p.reset(new T(...)) 等价于先释放 p 当前管着的对象，再接管新的裸指针。p.reset() 等价于释放对象并变成空——p 仍然是一个有效的 unique_ptr，只是当前不管理任何对象。在第 5 章的缓存刷新、数据结构替换、临时对象的析构排序等场景中，"旧数据被新数据完全替换，旧数据的安全析构由管理者自动完成"这条逻辑，在 unique_ptr 上只需要一行 reset() 即可达成。
reset() 在工程中还有一个不容易被注意到的正确性保障：它先销毁旧对象再接管新指针。这意味着如果在接管新指针的过程中发生了异常（比如 new T(...) 在分配失败时抛出 std::bad_alloc），旧对象已经在异常到达调用方之前被安全释放了——释放和接管的顺序安排让异常发生的那一刻不存在"旧对象还活着但新分配失败的资源冲突"。这和之前讨论的"先释放后分配"异常安全问题恰好是互补的——在 reset() 中，释放旧对象发生在异常可能发生点之前，因此失败不会导致复合资源状态的歧义。如果顺序是反过来的——先分配新、再释放旧——而分配失败了，旧对象被完好保留，这也是安全的。换任何其他的手工实现顺序（比如把裸指针写进局部变量再做释放和替换），就很容易制造出"分配失败但裸指针已丢失"的中间出错窗口。reset() 没有覆盖全部异常安全场景，但在它所处理的"替换"语义上，它是足够严谨的。
release() 是这三个里面唯一一个把对象的所有权从类型系统交还给手工管理的操作，也是日常代码里最不应该使用的操作。p.release() 的唯一效果是在放弃管理的同时返回裸指针、把自己置为空——之后裸指针上附着的一切内存安全责任全部从 unique_ptr 消失，转移到了调用方手中。调用方不能在类型系统里找到任何能帮他记住"这个裸指针需要被 delete"的东西——他只能靠记住。如果在后续的任何一条控制流分支上漏掉了 delete，泄漏就是无声且必然发生的。
release() 在标准文档里存在的理由不是让你在 C++ 内部用它来"绕过"类型安全——它存在是因为存在着一个只有裸指针没有 unique_ptr 的外部世界：C 接口、老旧的第三方库、一些操作系统 API 不接受 RAII 类型只接收裸指针。当你的 unique_ptr 管理的对象需要被交给这种外部接口，并且该接口在文档中明确声明"调用方负责释放"时，release() 是把你手里的所有权转移到那个外部接口世界的唯一路径。到了那个世界之后，你必须确保在外部代码完成工作之后，有新的一层 RAII 包装或者明确的 delete 语句把所有权收回。一种常见的工程模式是：在紧邻 C 接口调用的代码层形成一个尽量薄的分界——release() 只在这一层出现，所有权一进入 C 层就由明确的手工管理控制，一旦从 C 层返回，立即重新封装 raw 进 unique_ptr——这样裸指针在所有内部 C++ 逻辑中都不可见，只有分界层能接触到所有权进出。三个操作在工程中的使用频率和风险分级可以这样概括：get() 是日常借用，频繁使用且安全；reset() 是状态替换，偶尔使用且安全；release() 是出境通道，极少使用且要求调用方承担此后的一切责任——如果你能在代码审查中删掉每一个不必要的 release() 调用，你就删掉了所有权管理中最容易出错的一类操作。
自定义删除器：unique_ptr 管理的可以不只是堆内存
在默认删除器的 unique_ptr<T> 之下，销毁对象的手段是 delete——unique_ptr 的析构函数调用 std::default_delete<T>，它等价于 delete ptr。但对于很多不由 new 分配、或不由 delete 释放的资源，unique_ptr 通过第二个模板参数——删除器类型——把它的管理边界从"堆对象"扩展到了"任何需要配对释放的资源"。
一个 C 库返回的文件描述符、一个 POSIX 信号量、一个 Win32 窗口句柄、一个 CUDA 流、一个 libcurl 的 easy handle——这些资源的共同特征是在获取之后需要用特定的释放函数来归还（close、sem_close、DestroyWindow、cudaStreamDestroy、curl_easy_cleanup），并且这种配对释放的契约在手工管理的代码中随时可能因为一条提前 return 或一个异常而被打破。unique_ptr 加自定义删除器的组合把 RAII 的框架完整地搬到了这些非内存资源上：
// 文件描述符——用 close 而不是 delete 来释放auto fd_deleter = [](int* fd) { if (*fd >= 0) close(*fd); };
std::unique_ptr<int, decltype(fd_deleter)> fd_guard(
new int(open("file.txt", O_RDONLY)), fd_deleter);
// C 库返回的资源——用对应的释放函数std::unique_ptr<FILE, decltype(&fclose)> file_guard(
fopen("data.bin", "rb"), fclose);
这两行代码把第 7 章中需要手写整个 RAII 类的场景压缩到了两行——而且没有丢失任何安全性：离开作用域时释放一定发生，移动后所有权正确转移，get() 仍然可以安全地借出裸句柄给接受 C 类型参数的函数。unique_ptr 在这个角色中不再是一个"智能 delete 指针"——它是一个泛化的 RAII 句柄，标准库替你实现了拷贝禁止、移动转移、借用查看和状态替换的全部模板代码，你只需要指定一个什么样的可调用对象来扮演"释放"这一步。
自定义删除器在工程上有一个需要特别留意的类型分歧问题。unique_ptr<T, DeleterA> 和 unique_ptr<T, DeleterB> 是两个不同的类型，即使 T 相同——它们不能互相赋值，不能放进同一个 std::vector。如果把带自定义删除器的 unique_ptr 暴露到公共接口上，调用方就被迫了解删除器的具体类型，而删除器通常是实现细节。标准做法是把自定义删除器封装在工厂函数或其他构造逻辑的内部，对公共接口只暴露默认删除器版本的 unique_ptr<T>。lambda 删除器没有名字，不能出现在函数签名中，这在实际中反而是一条好处——它天然地迫使你把删除器的定义藏在实现文件里，只通过 unique_ptr<T> 的接口层对外通讯。
自定义删除器的另一个影响是 unique_ptr 的大小。默认删除器受益于空基类优化，sizeof(unique_ptr<T>) == sizeof(T*)。但对于函数指针类型的删除器，unique_ptr 内部需要额外存储一个函数指针——此时它的大小通常是两个指针。对于捕获了状态的 lambda 作为删除器，额外存储就是 lambda 的捕获对象大小，可能是几个字节也可能是几十个字节。在嵌入式的极限内存约束下，或者当 unique_ptr 作为非常高频传递的小对象时，这是个值得知道的差异——但对于绝大多数常规场景，默认删除器的零额外空间已经覆盖了 95% 以上的使用频率。
接口是所有权流动的路标，类型即文档
前七章所有的论点——第 2 章的借用 vs 拥有、第 4 章的 new/delete 手工配对不可持续、第 6 章的五个特殊成员和资源所有权的联动、第 7 章的构造获取析构释放——都在指向同一个结论：所有权信息需要被编码进类型系统，因为类型系统是 C++ 里唯一一个能在编译期对所有执行路径强制执行约束的东西。unique_ptr 恰是这个结论在"只有一个拥有者"这个场景下的完整实现。
当一个工厂函数签名为 std::unique_ptr<Widget> MakeWidget() 时，返回的不仅是一个 Widget*——返回的是一个附带了"唯一所有权"标签的 Widget。调用方接手了所有权，必须承担释放（或继续往下传）的责任。当一个消费函数签名为 void Consume(std::unique_ptr<Widget> w) 时，参数的不仅是一个 Widget 的访问权——该函数明确声明了"我把这个对象的所有权吃掉，你传入之后就不要再多管它了"。对一个以 const Widget& 作为参数的函数而言，它传达的信息同样清楚：这个函数只读、不碰你的所有权、不参与这个 Widget 的生命周期管理。
这三类模式——返回 unique_ptr 传出所有权、接收 unique_ptr 接管所有权、接收 const T& 读取而不参与所有权——合在一起覆盖了函数间对象传递的绝大多数场景。它们不需要注释来解释所有权——类型本身既表达了接口的契约，也作为编译器强制执行所有权不变量（不能被拷贝、不能被意外共享、不能在接管所有权的函数里忘了释放）的唯一依托。
工程中有一个特别值得注意的转折点发生在裸指针的角色被收窄之后。在现代 C++ 代码库里，裸指针不应该再被用来表达所有权——它所有的所有权路径都应该被 unique_ptr 和（下一章的）shared_ptr 替代。裸指针剩下的那一个合法角色是表达"可空的非拥有观察"——Widget* 在参数列表里的语义收敛为"我可能需要也可能不需要访问一个 Widget，但我绝不负责释放它"。这个收敛让它和 const Widget&（不可空、只读）以及 unique_ptr<Widget>（独占、不可空、拥有）形成了一套完整且互不重叠的接口语义体系。处理遗留代码时，这套体系也提供了一个清晰的迁移方向：当你看到函数参数里有一个 T* 时，先问"这个函数是借用还是接管所有权"，如果是借用就保留裸指针（或视情况改为 const T&），如果是接管所有权就改成 unique_ptr<T>——接口的每一次翻新都把所有权语义从注释中搬出一个，放进类型中。
在阅读和理解已有代码库时，unique_ptr 还有一个显著的信息压缩效应：如果一个类拥有 unique_ptr<ExpensiveResource> 成员，那么阅读者不需要再去翻看该类的析构函数来确定 ExpensiveResource 是否被释放了、释放是否正确——答案直接从成员类型上读取，不需要审阅析构函数的实现。如果一个函数返回 unique_ptr<Result>，阅读者不需要去找调用方的对应释放点来判断"这个函数内部分配的东西是不是需要我在外面释放"——返回类型已经在告诉调用方：是的，而且只交给你一个。每少看一个析构函数的内部实现、每少审阅一列释放代码的正确性，都是代码阅读的认知负载降低，而且这种降低不是偶然的——它是因为所有权信息已经从代码逻辑里提升到了类型声明上，而类型声明是所有阅读者第一眼扫描的部分。
PIMPL（Pointer to Implementation）惯用法是 unique_ptr 在现代 C++ 中承担信息压缩角色的一个典型应用。当你把类的实现细节全部隐藏在一个前向声明的 Impl 结构体后面，并通过 std::unique_ptr<Impl> impl_ 来管理它时，unique_ptr 同时完成了三件事：它把实现细节的编译期依赖从客户端彻底隔离（客户端不需要 #include 实现细节的头文件），它用独占所有权保证了实现对象与外部对象的一对一生命周期绑定，它用零额外空间避免了这个惯用法的内存代价。PIMPL 加上 unique_ptr 是现代 C++ 中保持 ABI 稳定和编译速度最快的惯用法组合之一——而这两个目标在实现层面上都受益于 unique_ptr "独占管理、零空间开销、编译器生成正确析构"的三重属性。
在默认删除器之外，unique_ptr 通过自定义删除器将其管理边界扩展到任何需要配对释放的资源——文件描述符、信号量、窗口句柄、CUDA 流——这些资源的共同点是需要一个特定的释放调用而不是 delete，而自定义删除器让 unique_ptr 的 RAII 框架完整覆盖了这些跨出标准 C++ 自由存储外的资源类型。
还有一条在工程中非常常见的所有权升级路径：当你最初设计一个模块时，某个 Widget 的生命周期由单一拥有者决定——你用了 unique_ptr。后来需求演进，第二个模块也需要延长这个 Widget 的生命周期，并且在第二个模块的生命周期内不能让第一个模块独自销毁 Widget。此时你可以把 unique_ptr "升级"为 shared_ptr——std::shared_ptr<Widget> sp = std::move(up); 这一行代码把 unique_ptr 内部管理的裸指针的所有权转移进 shared_ptr 的控制块体系，unique_ptr 变为空。这一行同时也是所有权模型的转变：从独占变成了共享。这里没有一个普遍适用"应该升级"还是"应该保持独占"的答案——正确的选择完全取决于你的模块图里对 Widget 的生命周期到底有几个所有者。但也正是这种向上升级路径的存在，让你可以在设计初期先用 unique_ptr 把独占关系锁紧——如果不确定将来是否需要共享，宁可先用独占把正确的语义约束建立起来，而不是一开始就选择代价更高、约束更松的共享所有权。后面确有需要时再升级是单向的简单操作，从共享降回独占到无法自动完成的。
整条推导链从前七章走到本章到达了一个关键节点：在第 4 章和第 5 章里，"分配、构造、析构、释放"四个动作是分散的；在第 6 章里，五个特殊成员函数的联动方式被确立；第 7 章用 RAII 把这些部件装配成了一个以"构造获取、析构释放"为核心骨架的框架；而本章用 unique_ptr 证明了这套框架在一块最常见的工程需求——独占所有权的动态对象——上可以交付比任何手工管理都更安全、更清晰、并且零运行时代价的类型安全方案。但独占不是所有关系的全部——工程中确实存在"多个模块需要共享同一个对象的生命周期"的需求，这个需求就是第 9 章要进入的 shared_ptr 和 weak_ptr 的领域。两种智能指针共享同一个 RAII 骨架，由此产生的差异源于一个本质问题：所有权独占了还需要共享吗？如果需要共享，控制块的引入、引用计数的管理开销以及循环引用带来的设计约束就成了必须面对的代价。
阅读导航
