C++ 资源管理接口：借用、接管与共享所有权
10 接口里的所有权要写清楚
下面四个函数的签名都合法，都能通过编译，都能在参数列表里接收一个 Image 对象：
void Draw(const Image& image);
void Draw(const Image* image);
void SetCache(std::unique_ptr<Image> image);
void ShareCache(std::shared_ptr<Image> image);
这四个函数对 Image 的所有权关系却完全不同。第一个只读借用——调用方手里的 Image 在 Draw 执行期间必须继续活着，但 Draw 不碰它的生命周期。第二个是可空观察——可能传 nullptr 表示"没有图像可绘制"，同样不拥有。第三个是独占接管——SetCache 从调用方手里拿走了 Image 的完整所有权，调用方调用之后不再持有这个对象。第四个是共享保存——ShareCache 和调用方（以及未来可能的其他持有者）共同延长 Image 的生命周期，直到最后一个持有者放手。
如果你不用类型上的所有权信息去读这四个签名，它们只是程序员在不同时期随手写下的四种字符组合之间的个人偏好差异——"这个人喜欢引用，那个人喜欢指针，当时没想那么多"。一旦你把前九章铺设的所有权语义——借用和拥有的区分、unique_ptr 的独占契约、shared_ptr 的共享计数、weak_ptr 的观察角色——映射到这四组字符上，相同的源码立即开始说完全不同的话。const Image& 在说"我只读你的数据，不保留后门"。const Image* 在说"我可能需要也可能不需要一个 Image，不负责释放"。unique_ptr<Image> 在说"从这一刻起它是我的，我会在适当的时候销毁它"。shared_ptr<Image> 在说"我参与决定它什么时候不再被需要，我和其他人在这个决定上有同等权利"。
本章要做的就是把这条映射关系转化成一套在工程中可以逐条执行的设计准则。这不是关于"用什么类型能让代码编译通过"——用 T* 替掉 const T& 在任何场景下都能编译通过。这是关于"用什么类型能让函数的签名本身在不需要注释、不需要查看实现的前提下，精确地回答三个问题：我拥有这个对象吗？我需要释放它吗？我会持有它多久？"
先问"谁负责对象活着"，再选类型
在动手写函数签名之前，有一个问题的优先级高于一切语法选择：当前模块对你即将接收或返回的这个对象，有没有延长其生命周期的责任？这个问题把 C++ 接口里的所有权关系分成了两个大类——不拥有和拥有——每一类内部再用可空性与访问权限做细分。
不拥有意味着函数（或类）在任何情况下都不会去负责销毁这个对象，也不会通过保存一个指针或引用来让对象在调用结束之后继续存活。这类语义在 C++ 类型体系里有四个标准入口——const T&（必然存在、只读）、T&（必然存在、可修改）、const T*（可能为空、只读）、T*（可能为空、可修改）——它们各自对应的参数或成员变量上，调用方和实现方之间的契约一目了然：调用方保证调用期间对象活着，实现方不存储指向该对象的任何持久引用。如果一个函数把 const T& 偷偷存进了全局容器或类的成员里——不管它存的是引用、是指针、还是别的什么形式——它就破坏了这个契约，因为对象在调用结束之后继续被外部引用，而那条引用是否还能解出有效对象则完全取决于调用方是否仍然持有着它。函数签名承诺的是"我只在调用期间用你"，实现如果超出了这个承诺，应该改用和实际行为一致的、能表达延长生命周期语义的类型。
这个判断还有一个容易被忽略的面向：返回引用或返回裸指针同样宣告了不拥有的语义。如果一个成员函数返回 const T&——const std::string& name() const { return name_; }——它宣告的是"我让你看一眼我的内部状态，你绝对不要尝试释放它，也不要在我的生命周期之后继续持有它"。调用方拿到这个引用之后，它的有效期严格等于该对象的剩余生命周期——对象析构之后，继续持有这个引用就是悬空。如果一个函数返回 T*，语义也是如此——除非函数的文档中显式表明返回的裸指针需要由调用方释放。而文档中的这句话在现代 C++ 里更合适的表达方式是把返回类型直接写成 std::unique_ptr<T>，让类型本身消除文档的必要性。
拥有意味着函数或类需要接管对象的生命周期控制权，或者需要与调用方共享这一控制权。独占接管 → std::unique_ptr<T>（按值参数表示接管，按值返回表示交出）。共享保存 → std::shared_ptr<T>（按值参数表示参股共享所有权，按值返回表示将共享所有权交出给调用方，成员变量表示本实例是该共享组的成员）。观察共享对象但不延长生命周期 → std::weak_ptr<T>。这三类中，std::unique_ptr<T> 的语义最精确、运行时代价最低——它是所有"动态对象所有权通过接口传递"的默认首选，只有在确切存在多个独立持有者时才需要升级为 std::shared_ptr<T>。
在函数参数中，按引用传递 const std::shared_ptr<T>& 和按值传递 shared_ptr<T> 看起来几乎一样——差了一个 & 和一个 const——但它们在所有权语义上的鸿沟比语法差异大一整个数量级。引用传递意味着函数根本不增加引用计数，因此函数完全没有参与延长对象的生命周期——它只是一个借用 shared_ptr 本身的观察者，而不是一个共享所有权的参与者。这种写法在极少数需要"先检查 shared_ptr 是否为空再决定是否要拷贝一份来延长生命周期"的路径上有其合理性，但在日常接口中出现时，多数情况下是调用者不清楚自己在所有权上的角色定位——不确定是否该共享、不想承担共享的成本但用了 shared_ptr 的类型——于是把 const shared_ptr<T>& 当成了一个没有语义约束的万能传参方式。绝大多数函数应该借用的是对象本身（const T&），而不是借用一个管理对象的智能指针——后者多了一层间接，模糊了借用关系的指向目标，也在签名上凭空引入了一个和当前函数所有权决策无关的智能指针类型。
这条反模式有一个精确的诊断标准：如果一个函数的参数是 const std::shared_ptr<T>&，而它的实现从头到尾只调用了该参数的 operator* 或 operator->——即它只使用了托管对象本身，从未拷贝该 shared_ptr——那么该参数应该改为 const T&（如果对象必然存在）或 const T*（如果可以空）。const shared_ptr<T>& 的唯一合法用途是：函数在条件满足时需要通过拷贝参数来延长对象的生命周期（从而成为共享组的成员），而在条件不满足时不想支付原子计数的开销。这条路径极为狭窄——它只在"可能延长也可能不延长"的二元分支中存在——在任何其他路径上，const shared_ptr<T>& 都是在用更复杂的类型表达更少的语义信息。
借用：引用和裸指针的语义已经收窄到一个非常精确的区间
在所有不转移所有权的接口模式中，const T& 是使用频率最高的默认选项。它表达的是最干净的非空只读借用契约——调用方提供一个必然存在的对象，函数在调用期间读取它的状态，调用结束后函数不保存任何指向该对象的引用或指针。编译器在编译层面上也会帮忙维护这条契约的一部分：const T& 不能用于 delete，不能通过它修改对象，不能把它绑定到一个即将消亡的临时对象（除非触发引用生命周期延长那条特殊规则——即使如此，延长后的生命周期也绑定到了引用变量自身的作用域，而不是函数调用的作用域）。
const T& 作为借用通道还有一个隐性的好处：它天然地适用于多态。如果一个函数的参数是 const Base&，调用方可以传入任何 Base 的派生类对象的引用——不需要做任何指针转换。这种多态性在用 T* 或 unique_ptr<T> 传递时虽然也是成立的，但在 const T& 版本中它不带任何跟所有权相关的语义干扰——读你就只是读你，无论你实际的动态类型是什么。
T&（非 const 引用）在 const T& 的基础上增加了一层修改权限——函数不仅仅在读取调用方对象的状态，同时也在修改它，并且修改在函数返回后对调用方是完全可见的。T& 和输出参数（T* 或 T& 用于输出）在语义上属于同一条路径，区别只在于输出参数不会在入参时携带有效值——但 C++ 类型体系对这两者的区分并不做强制检查，全凭命名和注释。"何时用 T&、何时用 T*（作为入参的可修改借用）"在历史上曾经是一个编码风格的长期论辩，但自 std::optional 和智能指针接管了所有权后，这个辩题的核心已经无关所有权——可修改借用的引用和裸指针在非拥有语义下是完全同构的，选择哪个取决于团队约定和可空性需求。
T* 和 const T* 在现代 C++ 接口库中的角色被收窄到了一个极其精确的区间：可空的非拥有观察。const T* 的语义就是"我可能需要也可能不需要访问这个对象，我绝不负责释放它，对象生命周期由调用方全权管理"。这种收窄使得裸指针从早期 C++ 中的"全能类型"——有时候是借用、有时候是拥有（需要 delete）、有时候是数组（需要 delete[]）、有时候是指向函数内静态变量的只读指针——收敛为了类型体系中的一个单一职责成员。在全系列的推导链上，这是一个重要的认知支点：裸指针不表达所有权，不是因为它被淘汰了——而是因为 C++ 现在有了更精确的工具去各自独立承担那些曾经全压在裸指针身上的职责。
处理遗留代码时，这套收窄也是逐文件评审所有权的检查表的最佳入口。看到一个 T* 参数——它在当前代码中实际扮演的是什么角色？如果它在做借用且不涉及 null → 改成 T& 或 const T&。如果它在做可空借用 → 保留 const T* 或 T*。如果它实际上是在接管所有权（函数内某处有 delete）→ 改成 unique_ptr<T>。如果它实际上是传出所有权（函数返回了一个需要调用方 delete 的裸指针）→ 改成返回 unique_ptr<T>。如果它实际上是在传数组 → 改成 std::span<T>（借用）或 std::vector<T>&（可修改借用）。类型升级不必一次性做完全局，在每次触碰到一个旧接口时做局部修正，把所有权从裸指针的沉默中搬一个出来放进类型系统的声明层——每搬一个，那个接口的所有权语义就对全部后续阅读者和维护者永久可见。
除了引用和裸指针，构造一个对象的"借用"语义还可以通过 std::span<T>（连续数据的借用视图）和 std::string_view（字符串的借用视图）来表达。这两个类型第 3 章已经介绍过，但在接口设计场景中它们的位置需要特别标出：它们是不拥有、不负责释放、生命周期比数据源短的一层轻量视图——当你的函数只是遍历一段已有的连续内存或读取一个已有的字符串时，用 span 或 string_view 比用 const vector<T>& 或 const string& 更好，因为它们和底层容器类型解耦——同一个 span<const int> 参数可以接收来自 vector<int>、array<int, N> 和 C 风格数组的数据，不强制调用方把数据装进特定容器类型。std::span 在接口设计中还有一个常被忽视的作用：它同时携带了地址和长度两个信息，把第 3 章中"数组退化丢失长度"的问题在接口层面从根本上消解了——一个接收 std::span<const T> 的函数不需要同时接收一个 size_t 参数，也不需要信任调用方提供的长度与数组实际长度一致，因为 span 在构造时就从底层数组或容器的实际元素数量中推导出了正确长度。这种"把地址和边界打包成一个不可分割的参数"的语义，恰好是所有权管理中"信息完整性"这一命题在借用方向上的自然延伸——不拥有所有权的视图，也应该完整地知道自己所观察的范围。
接管：unique_ptr 在所有权的进出点上不说话都不行
当一个工厂函数返回 std::unique_ptr<Widget> 时，它在签名层面同时宣告了两条信息：调用方获得了 Widget 的唯一所有权，并且在不需要该对象时负责触发它的销毁（或继续把所有权向下游传递）。这条信息在返回 Widget* 的旧式工厂里是完全不可获取的——Widget* CreateWidget() 的返回值既可能是需要调用方 delete 的堆对象，也可能指向工厂内部的静态缓存区完全不需要释放，也可能已经被某个 shared_ptr 管理系统接管了所有权。面对这个 Widget*，调用方有三种可能的释放方式，而类型签名上没有任何比特在告诉他是哪一种。把返回类型改成 unique_ptr<Widget>，等于把这三选一的可能性从运行时的暗箱里提出来，放进了编译期的白光。
unique_ptr 的移动语义是这条所有权进出的关键枢纽。当一个函数接收 std::unique_ptr<Widget> 按值参数时，调用方必须在调用点上写 std::move(p)——这不是语法噪音，它是调用方在源码上留下的唯一的、可见的"我放弃了所有权"的宣言。读到这行代码的维护者不需要去追溯 p 在调用之后的存活状态——std::move(p) 告诉他们所有权已经离开，p 此后不再是 Widget 的管理者，后续代码中任何继续使用 *p 的行为要么是逻辑错误（如果 p 之前没有经过 nullptr 检查），要么是合法的语义（如果 p 被置空后只做了空值检查）。
按值返回 unique_ptr 同时也是现代 C++ 中从工厂函数输出所有权的标准形态。编译器会对按值返回局部 unique_ptr 的工厂函数应用 RVO（返回值优化）——在绝大多数编译器和绝大多数调用形态下，unique_ptr 直接在调用方的栈帧上被构造，不经过任何移动构造或拷贝构造。调用方用 auto w = CreateWidget() 接收返回值，w 就是 Widget 的唯一拥有者，从创建到接管没有一次裸指针暴露到了调用方的可见代码区域。
在类的内部，unique_ptr 作为成员变量——std::unique_ptr<Impl> impl_——是表达"本类独占拥有该子对象"的标准方式。当持有这个成员的类析构时，unique_ptr 的析构会自动销毁子对象，不需要在析构函数里手写 delete impl_；当持有类被移动时（如果编译器生成的移动构造函数可用），unique_ptr 的移动自动清空源对象的 impl_——整条所有权链在成员层级上自动逐级传递，不需要任何手写控制。这也是 PIMPL（Pointer to Implementation）惯用法中管理隐藏实现对象的自然选择——unique_ptr 的零额外空间、禁拷贝允许移动的语义，和 PIMPL 对外部类的需求高度吻合。
自定义删除器在 unique_ptr 的接口层有一个额外的考虑值得单独点明：因为删除器是模板参数的一部分，unique_ptr<T, MyDeleter> 和 unique_ptr<T, DefaultDeleter> 是两个不同的类型，不能互相赋值，不能放进同一个 std::vector。如果你的代码库中某段逻辑依赖在删除器版本不同的 unique_ptr 之间交叉传递，需要及早把自定义删除器的使用封装在工厂函数或其他内部逻辑之后，对公共接口保持默认删除器的类型一致性。对外一律暴露 std::unique_ptr<T>（默认删除器），把各种需要不同释放逻辑的 T* 在工厂函数内部装上对应的删除器，然后以一个统一的 unique_ptr<T> 返回给调用方，调用方从此不需要关心删除器的具体形态。
共享：shared_ptr 进入接口的唯一通行证是"需要延长生命周期"
std::shared_ptr<T> 在接口中的使用条件可以用一句话概括：函数需要延长传入对象的生命周期，并且这个延长不能通过 unique_ptr 的单向传递来实现——因为对象的生命周期是由多个模块共同决策的。如果一个函数的整个调用周期内只需要临时访问对象——读它、在它上面调用一些方法、修改它的一部分状态——然后调用结束就再也不需要它，那 const T& 或 T* 就是完全满足这组语义的类型，shared_ptr 没有出现在签名上的任何必要性。"但万一将来需要共享呢、现在用 shared_ptr 提前预留"这种推理是把设计决策的时间点从"将来需求确认时"提前到了"现在还不确定时"，而提前付出的代价——控制块分配、原子引用计数、两倍指针大小、以及代码阅读者对着 shared_ptr 签名去猜测是否存在多持有者的认知负载——是无法在将来被回收的沉没成本。unique_ptr 向 shared_ptr 的单向升级路径（std::shared_ptr<T> sp = std::move(up)）允许你在未来需求确认时一次性升级，一行代码，零代价——所以"不确定"不是选择 shared_ptr 的理由，"确定有多个持有者"才是。
当 shared_ptr 作为成员变量出现在一个类的声明中时，它说的是：只要本类的实例仍然存活，该对象就不会被销毁——而本类不是唯一拥有这种"否决销毁权"的实体。阅读这段代码的人必须立刻追问：还有谁持有这个对象？共享关系形成的图结构中有没有环？环上的哪一条引用可以用 weak_ptr 破开？这三个问题在 unique_ptr 成员上完全不会被触发——unique_ptr 成员的语义是"只有我"，不需要考虑其他人。这就是前面九章一直强调的"能用 unique_ptr 就不用 shared_ptr"在设计层面的映射：unique_ptr 让接口只产生一个问题（"我什么时候释放它"），shared_ptr 让接口产生一堆问题（"除了我还有谁""引用图有没有环""谁的析构先发生""最后一个持有者是谁"）。
按值传递 shared_ptr<T> 作为函数参数时，调用的每一次都触发一次原子递增和一次原子递减（分别在函数进入时和退出时）。在绝大多数函数调用频次上这个成本是完全不可感知的——数十纳秒粒度的原子操作即便在常规业务逻辑中累积到十万次调用也不到一毫秒。但如果相同的 shared_ptr 在每帧渲染的绘制循环里被逐条绘制指令拷贝——每次拷贝增加一次计数、每条指令结束时减少一次计数——这个不必要的原子操作频率就可能从"不可感知"变成"在性能采样图表上显露"。在这种场景下，循环外部持有一份 shared_ptr，循环内部只传 const T& 或 T*——借用路径上不需要碰引用计数。共享所有权的语义全局不变，局部高频路径上剥离了原子的负担。
std::weak_ptr<T> 在接口上的角色比 shared_ptr 更窄，但语义也更明确：这个函数观察一个共享对象，但不参与所有权的决策。如果一个类把 weak_ptr 作为成员——无论是缓存索引、观察者列表、还是异步回调的上下文指针——它的意思就是"我知道外面可能有一个由 shared_ptr 群体管理的对象，我想在需要时安全地访问它，但我不应该阻止它在没有人需要时被销毁"。lock() 是 weak_ptr 打开这扇观察窗的唯一钥匙——它返回一个临时 shared_ptr，在当前作用域内保证对象的生命周期不被中断；如果对象已经析构，lock() 返回空，程序安全地退出观察逻辑。weak_ptr + lock() 的组合是 C++ 在不使用 GC 的语言框架下，为"安全地观察一个可能不存在的对象"提供的唯一标准解决方案。
在 shared_ptr 和 weak_ptr 共同出现的接口场景中——比如一个对象既要被多个模块共享，又要被缓存层索引——一个常见的设计误差是把缓存层也声明为 shared_ptr 的持有者，而缓存层的本意并不是延长对象的生命周期，只是在对象存活期间提供快速查找。用 shared_ptr 表达这种索引关系会无意中让缓存成为对象生命周期的参与者——缓存不销毁，对象就永远不会被释放，即使所有真正的"业务"持有者早已离开。换成 weak_ptr 就刚好——缓存不阻止对象销毁，对象销毁之后 lock() 返回空，缓存可以从索引中清除对应条目。所有权关系在缓存层的声明类型上被精确表达：shared_ptr = 参股所有权，weak_ptr = 不参股所有权只观察。
工程中的默认决策链
把前九章从存储期到智能指针的完整分析链路全部收束到函数签名的决策上，最终只沉淀为一条不超过四个分叉的决策链。不需要画成纸质参考文献——只需要在写每一个函数签名时停顿五秒自问下面几件事，让这些问题的答案直接驱导类型的选择。
第一步：这个函数对传入或返回的对象是否有生命周期管理的责任？没有 → 进入「借用与观察」分支。有 → 进入「拥有」分支。
第二步（借用与观察）：对象在调用期间必然存在吗？必然 → 用 const T&（只读）或 T&（可修改）。不必然，可空 → 用 const T* 或 T*。在需要表达"一段连续数据的借用视图"时，优先用 std::span<const T> 或 std::string_view 替代 const T*——这些视图类型把地址和长度打包成一个可传递的、类型安全的整体，在传参时不会因为丢失长度信息而引入越界风险。这也是前九章推导积累下来的一个具体结论：当类型系统可以帮你同时携带地址和边界信息时，不要退回到只携带地址的裸指针。
第三步（拥有）：独占还是共享？独占 → std::unique_ptr<T>。按值参数 = 函数接管所有权，按值返回 = 函数交出所有权。共享 → 进一步判断是否需要本模块参与延长对象的生命周期。
第四步（共享场景）：需要延长生命周期 → std::shared_ptr<T>（作为参数拷贝传入、作为返回值传出、或作为成员变量存储）。不需要延长生命周期、只观察 → std::weak_ptr<T>（通过 lock() 确认对象存活后进行安全访问）。
这四步覆盖了 C++ 业务层代码中绝大部分函数间对象传递的所有权决策场景。剩下少数边界案例——比如需要高效非拥有指针但又要避免 T* 的可空语义扩散到外部接口——可以引入 std::optional<std::reference_wrapper<T>> 这类构造，但它们是专用扳手而非日常螺丝刀。
决策链在实际工程中运行时，有几个高频的"灰色场景"值得单独解析以免误用。第一个场景：一个函数接收了一个对象，需要在函数内部跨多次调用保存对它的引用——比如一个解析器接收了输入字符串的 const std::string&，但解析过程分成了多个内部阶段，每个阶段都需要读输入。这种情况下，把 const std::string& 在函数顶层接收之后传给内部子函数——只要内部子函数不把这个引用存入任何比当前函数调用更长寿的容器或成员中——就是完全安全的借用传递。但如果某个内部子函数把这个引用存进了类的成员变量，那个成员变量就越过了函数调用周期的安全边界——这时必须从"保存引用"升级到"保存 shared_ptr"或"把输入的 string 值拷贝一份到成员中"。函数的签名没有变——它仍然是 void Parse(const std::string& input)——但内部实现的正确性边界取决于"引用被存了多少层"这个事实，而不是签名上写了什么。
第二个灰色场景：一个类的成员函数返回了内部状态的引用或裸指针——比如 const Config& GetConfig() const。这个返回类型的语义很清楚——类不交出 Config 的所有权，调用方不应该长时间持有这个引用越过类对象的生命周期。但实现上，如果类内部用 std::unique_ptr<Config> 管理 Config，在类的移动操作中 Config 的所有权会被转移到新对象中，而旧对象中如果有人持有了之前拿到的 const Config&——现在它悬空了。用 shared_ptr<Config> 替代 unique_ptr<Config> 作为成员不会自动解决这个问题——调用方拿到的仍然是 const Config&，引用仍然不能延长生命周期。解决方案要么是在文档中明确"调用方不能长期持有返回引用"，要么是改变返回类型为 std::shared_ptr<const Config> 让调用方显式参股共享所有权。类型收束逼出了设计决策：如果这个 Config 需要在对象被移动后仍然被外部持有，那"共享"不是多余的——它是正确表达这条需求所必需的所有权模式。
第三个场景是容器和智能指针的组合——std::vector<std::unique_ptr<Widget>> 与 std::vector<std::shared_ptr<Widget>> 之间的选择。前者意味着"这个容器独占所有 Widget，容器销毁时所有 Widget 一并销毁，外部如果需要访问只能通过借用"。后者意味着"容器和外部持有者共同决定每个 Widget 的生命周期"。两者的边界不在语法层面——在于业务逻辑上，容器里的 Widget 是否被容器外的其他模块也以拥有者的身份持有。如果你在一个场景中选择了 vector<shared_ptr<Widget>> 仅仅是因为"方便从容器里取出来传给外部使用"，那 vector<unique_ptr<Widget>> + 外部借用（const Widget& 或 Widget*）在绝大多数情况下既能满足使用需求，又避免了把所有权结构扩散到不必要的共享范围。如果外部确实需要延长某个 Widget 的生命周期——比如取出来放进一个异步任务队列——那 shared_ptr 就是正确的选择，但此时你应该能明确地指出"异步任务队列是这个 Widget 的第二持有者"。
对于函数返回值，有一条特别值得单独强调的经验规则：优先按值返回而非通过输出参数传递智能指针。std::unique_ptr<Widget> Create() 按值返回给调用方——RVO 在绝大多数场景中使这个返回零开销，调用方在调用点的 auto 接收也直接坐实了"我接管了所有权"的语义。相比输出参数 void Create(std::unique_ptr<Widget>& out)——调用方需要预先声明一个空的 unique_ptr，然后把它按引用传给工厂函数，工厂函数在内部把它赋值——按值返回的语义更直接、调用点上的意图更易读、和 C++ 的值语义惯例也更一致。只有在一种输出参数仍然优于按值返回的场景：函数需要在返回新对象的同时，还返回额外的状态信息——比如一个错误码——而此时 C++17 的结构化绑定或 std::expected（C++23）还没有进入项目的工具箱。在那种过渡期的代码中，bool Create(std::unique_ptr<Widget>& out) 可以作为一种临时妥协，但你应该清楚这是语法工具的局限，而不是设计上的偏好——一旦项目条件允许，改成按值返回配上 std::optional 或 std::expected 就把所有权语义重新对齐到类型表达上。
工程中另一个常见的返回值场景是条件性创建——"如果满足条件就返回一个对象，否则返回空"。在这种场景下，std::unique_ptr<T> 已经天然支持空状态（nullptr），所以返回 std::unique_ptr<T> 就可以表达"有或没有"的语义，不需要额外引入 std::optional<std::unique_ptr<T>> 双层包裹。调用方用 if (auto w = CreateIfNeeded()) 直接接收和判空——unique_ptr 本身的 bool 转换运算符在此充当了 optional 的判存在功能，零额外类型开销。如果条件性返回的同时需要携带失败原因（不只是"没有"），C++23 的 std::expected<std::unique_ptr<T>, ErrorCode> 比"返回 nullptr 同时把错误码写在输出参数里"在语义上完整得多。
工程中常见的所有权反模式
反模式的第一条：把 shared_ptr 作为默认的堆对象管理方式。"用 shared_ptr 总比裸指针安全"这个直觉在单个维度上是成立的——相比裸指针，shared_ptr 确实消除了忘记 delete 的风险。但它同时引入了三组新问题：编译期不再能检测非法的共享（任何拷贝都合法），所有权图可能在不被察觉的情况下形成环，以及类型上不再能区分"这个函数只是临时使用对象"和"这个函数正在加入共享组"。用 shared_ptr 替换裸指针是在用一组新的风险替换旧的风险，而不是在消除风险。正确的替换路径是：裸指针的所有权用途 → unique_ptr，裸指针的观察用途 → T* 或 const T&，裸指针的共享用途 → shared_ptr。每一个裸指针的替代方向取决于它的所有权语义，不存在一个统一替换所有裸指针的"安全类型"。
反模式的第二条：在接口上混用多个层级的智能指针。"工厂返回 shared_ptr，消费函数接收 unique_ptr（通过 release() 从 shared_ptr 中取出裸指针再构造），缓存层用 weak_ptr，查询接口返回引用"——这种多层级的类型混用通常不是因为设计上需要这些不同的语义，而是因为在写每个接口时没有把所有权决策放在优先位置，导致每个接口独立选择了一个"当时能编译通过"的类型，最终形成了所有权语义在同一个对象上的碎片化表达。修复的方式是从对象的创建点出发，沿着所有传递路径逐一标注每个接口对它的所有权角色，然后把不一致的类型统一到同一个所有权层级上。
反模式的第三条：使用 const std::shared_ptr<T>& 作为参数来"节省原子操作的开销"。这个写法的隐含假设是：函数基本上不需要延长对象的生命周期（所以传引用省掉原子计数），但偶尔需要（所以参数是 shared_ptr 而不是 const T&）。在绝大多数出现这个模式的实际代码中，函数的实现在所有控制流路径上都没有拷贝该 shared_ptr——即它从来不需要延长生命周期——这意味着参数本应是 const T&。只在极少数"概率性延长生命周期"的路径上，const shared_ptr<T>& 才是合理的——而即便如此，函数内部这个"偶尔"也应该局限在一个明确的、用 if 标记的局部作用域内，并且拷贝 shared_ptr 的操作应该紧跟着出现，而不是作为成员变量存储进全局状态。"省掉原子操作"是一个真实的性能论点——但它只适用于在被性能采样证实的瓶颈路径上做局部优化，不适用于作为常规 API 的默认传参方式。
反模式的第四条：在构造函数中接收裸指针并把它存为 shared_ptr 成员。"构造函数接收一个裸指针，然后从它构造一个 shared_ptr 保存到成员中"——这个模式在没有其他上下文时是完全合法且安全的，前提是这个裸指针是"新鲜"的、没有被任何其他 shared_ptr 管理过。但如果调用方传入的裸指针来自某个已有的 shared_ptr 的 .get()，双控制块的双重释放就完整铺设。把构造函数的参数从 T* 改成 std::shared_ptr<T>（或 std::unique_ptr<T>，视所有权而定），就把"这个对象必须是新的或必须已经被共享管理"的契约从注释迁移到了类型系统，编译器不能帮你检查裸指针的来源，但类型系统能强迫调用方在调用点就显式地把所有权关系暴露出来。
全系列的终点：所有权不再是一句注释
第 1 章和第 2 章建立了对象的位置和访问方式之间的区分——"名字""地址""指针""引用"各是什么，哪类访问承担释放责任。第 3 章把数组的边界丢失问题关联到了所有权信息的丢失——当你不知道一块连续内存从哪开始到哪结束时，你也不具备安全释放它的全部信息。第 4 章和第 5 章拆开了 new/delete 的四步机制和对象的完整生命周期线——从分配、构造到析构、释放，每一个动作由不同的机制驱动。第 6 章把五个特殊成员函数的联动方式和资源所有权的耦合关系放在了同一张设计图上。第 7 章用 RAII 把这些分散的部件装配成一个以"构造获取、析构释放"为核心骨架的管理框架。第 8 章和第 9 章分别把独占所有权和共享所有权编码进了 unique_ptr 和 shared_ptr/weak_ptr 的类型语义，证明了所有权的三套模式——独占、共享、观察——都可以以零额外运行时代价（unique_ptr）或可控代价（shared_ptr）的方式嵌入到每一条函数签名和每一个成员变量里。
这一章——本系列的最后一章——要交付的不是新的机制、不是新的语法，而是一个在任何 C++ 代码库中都可以立刻执行的判断准则：当你写下一个函数签名时，让类型本身而不是行注释来回答"谁拥有这个对象"、"谁释放这个对象"、"谁只是借来看看"。因为类型签名在每一次编译时都被编译器看在眼里——任何试图把 unique_ptr 拷贝来传递的代码都会被拒绝，任何试图把 weak_ptr 直接解引用的代码都会被拒绝——所有权契约在代码的物理文本上不再是程序员之间的口头约束，而是编译期机械执行的硬约束。
这十个章节写了这么多字、画了这么多图，最后的结论可以压缩成一句话：资源管理的难度不在"怎么释放"——delete、close、unlock、Destroy 这些操作只是一行代码的事；难度在从获取点到释放点之间的每一条控制流分支和每一个模块的接口边界上，都有人清楚地知道释放会由谁、在什么时机、以什么方式触发。C++ 的类型系统是这三件事能被统一编码的唯一场所。用对它，所有权就不再是注释里随时可能过期的客气话，而是编译器替你在所有代码路径上日复一日执行的无声检查。
阅读导航
