在我们自己的项目里，裸指针new出来的对象迟早会变成一块烫手山芋。早年间写C++，最头疼的不是语法难，而是到了一天结束要一个个检查析构顺序：这个接口返回的指针到底归谁释放？那个缓存里的对象是不是已经被别处delete了？这些问题在代码量小的时候还能靠纪律硬扛，项目一过万行基本就是连环雷。所以我一直觉得，指针管理这件事，本质上不是语法问题，而是"所有权"的归属问题——谁创建、谁持有、谁负责销毁，这个链条一旦含糊，内存问题就会像滚雪球一样出现。
今天这篇是20天学C++系列的第16天，终于轮到智能指针。这不是一个可以随便跳过的知识点，它是老牌C++程序员转向现代C++的关键分水岭。理解智能指针，不只是学会用几个类模板，而是把"资源管理"这件事用RAII的方式重新理解一遍。我会从最原始的痛点讲起，先搞清楚裸指针到底哪里让人不放心，再逐个拆解unique_ptr、shared_ptr、weak_ptr的底层机制、典型应用和容易踩的坑。看完这篇，你至少能回答三个问题：为什么不能继续用auto_ptr？shared_ptr的性能成本到底花在哪里？以及weak_ptr在什么场景下真的能救命。
1. 为什么学了这么久C++才轮到智能指针
很多人学C++，一开始接触的是裸指针。那时候你眼中的指针大概是这样的：一个变量，存着一个地址，用new分配内存，用完记得delete。听起来很简单，但真到了多人协作、函数嵌套调用的项目里，这个"记住"根本做不到。我见过最典型的一个例子是某个工具模块里，一个函数返回了内部缓存的对象指针，调用方拿到后以为是自己拥有的，直接delete了，结果模块下一次运行就崩溃。这种事故定不了谁的错，因为接口上没有写清楚"这个指针是该你释放还是不该你释放"。
智能指针解决的正是这个"规则模糊"的问题。它的核心设计思想叫RAII，中文一般翻译成"资源获取即初始化"，但我更喜欢把它理解为"资源和对象的生命周期绑定"。当你创建一个智能指针对象时，它在构造函数里取得资源；当这个智能指针对象离开作用域被销毁时，它的析构函数自动释放资源。你不用手动调用delete，因为析构是编译器和运行时自动保证的。记住这个原则：资源的所有权归某个栈上对象，栈上对象销毁时资源必定被释放。这是C++里最反直觉但也最优雅的设计——你不需要"记得"释放，你只需要确保对象构造成功。
传统C++里我们习惯先分配后释放，这带来两个问题：一是如果中间抛出异常，后面的释放代码根本不会执行，直接内存泄漏；二是如果多个出口都要return，你得在每个出口前面手动补delete。而智能指针把释放动作挂在了栈对象的析构上，无论是正常return还是异常栈展开，析构函数都会被调用，释放逻辑永不遗漏。这是用代码结构消灭"人工记忆"，而不是靠纪律。
智能指针还有一个重要价值，是明确表达"所有权"语义。什么叫所有权？就是"这个对象由谁负责释放"这一决策本身。裸指针没有携带这种语义，所以每次传参、赋值、返回都要靠注释和默契，而注释总会过期，默契总会被新人打破。智能指针把所有权变成类型系统的一部分：std::unique_ptr告诉你"独占所有权"，std::shared_ptr告诉你"共享所有权"，std::weak_ptr告诉你"我观察但不拥有"。编译器可以在你写错的时候直接报错，而不是留到运行时崩溃。下面这张对比表能看出它们之间的基本差异：
| 智能指针类型 | 所有权模型 | 引用计数 | 典型开销 | 主要用途 |
|---|---|---|---|---|
| std::unique_ptr | 独占 | 无 | 极低，几乎为零 | 工厂返回值、类成员、局部资源 |
| std::shared_ptr | 共享 | 有（原子） | 较高的计数开销+控制块内存 | 多个对象需要共同持有同一资源 |
| std::weak_ptr | 观察 | 有（弱引用） | 随shared_ptr实例化 | 打破循环引用、缓存、观察者 |
| std::auto_ptr（已废弃） | 转移式"伪"独占 | 无 | 极低但危险 | 只在C++98老代码里出现 |
2. 新项目里被默认选中的unique_ptr：如何用移动语义接管所有权
std::unique_ptr是C++11引入的，它的定位是"独占所有权"的智能指针。很多人第一次接触它是从老教材里的auto_ptr开始的，但C++17里auto_ptr已经明确被移除，原因是它的拷贝语义设计有严重缺陷。auto_ptr的拷贝是"转移所有权"：你用auto_ptr复制一个对象，被复制的那个会变成空指针。这种隐式转移会把原来的指针悄悄置空，导致代码行为完全不可预期。我记得以前拿auto_ptr做容器元素存储，排序算法内部做元素交换的时候，指针直接被搬走，原来的对象就莫名消失了。这类bug极难排查，因为代码表面上看不出任何问题。
unique_ptr和auto_ptr的根本区别在于：unique_ptr把"禁止拷贝"和"允许移动"分开处理。编译器层面，unique_ptr的拷贝构造函数和拷贝赋值运算符被删除，你如果写了auto p2 = p1;这种代码，编译直接报错。同时它提供了移动构造函数和移动赋值运算符，意味着你可以用auto p2 = std::move(p1);显式地转移所有权。这个设计把"转移"做成了一件需要用户明确表达的事情，而不是像auto_ptr那样偷偷摸摸地发生。理解这点，你就明白移动语义的目的是什么：它不是性能优化的花活，而是让资源的所有权变更清晰化、显式化。
unique_ptr的内部实现其实很简单，你可以把它想象成一个带析构行为的裸指针包装器。它保存了原始指针，重载了operator*和operator->，让你用起来几乎和裸指针一样顺手。析构函数里判断内部指针不为空就delete。值得注意的一点是，在release接口这里的设计颇有意思：它返回裸指针但不再负责释放，把所有权转移回调用者；reset接口则直接销毁当前持有的对象并接管新指针。
实际项目里，unique_ptr最常见的场景是工厂函数的返回值。比如你写一个创建日志器的工厂，类型是抽象基类，实现可能是文件日志、控制台日志、网络日志。如果返回裸指针，调用方必须读文档才知道要delete；如果返回unique_ptr，任何合格的C++开发者都知道要接手这个指针，而且可以安全地把它放进容器或类成员里。工厂函数返回unique_ptr还有一个重要优势：多态对象在析构时通过基类指针释放，只要基类析构函数是虚的，派生类的资源就能正确释放，这是裸指针时代最容易出错的点。
这里特别想聊一个我自己的项目经验。当时某个模拟环境需要维护一组动态生成的任务对象，每个任务有自己的生命周期，任务结束就要释放。我一开始是用std::vector<SomeTask*>来存，每次往容器里塞指针后，要在外面维护一个"是否已经delete"的标记。后来改成std::vector<std::unique_ptr<SomeTask>>，整个管理逻辑瞬间干净了：任务对象被容器独占，任务完成直接从容器里erase，unique_ptr析构自动释放。这个改动最大的收益不是节省了那几行delete代码，而是彻底消灭了一类状态错误——"指针还在容器里但背后对象已经没了"的情况，因为unique_ptr和对象生死完全绑定。
2.1 移动构造和赋值背后的内存转移过程
理解unique_ptr的关键在于移动语义。很多人写std::move(p1)的时候，迷迷糊糊觉得"好像是让p1变成右值"，但理解不透彻。这里我带你拆一下移动构造的执行细节。假设有std::unique_ptr<Foo> p1(new Foo);和std::unique_ptr<Foo> p2 = std::move(p1);，移动构造做了什么？其实就两步：第一步，把p1内部保存的Foo*指针复制给p2内部的指针变量；第二步，把p1内部指针置为nullptr。对unique_ptr来说，这只是一次8字节指针的赋值，开销极低。移动之后p1处于"空有效状态"：你可以对它赋值新指针，可以调用reset、get这些接口，但解引用它是未定义行为。
这个"被移动后仍然可析构"的设计很重要，因为标准库必须保证被移动的对象能安全析构。如果移动完p1是悬空状态，析构时调用delete就会崩，所以必须置空。实际经验里，我经常故意用移动语义来"转移并清空"一个成员，比如一个派生类接管基类传入的资源，基类此后不再关心它。这样代码语义很直观：所有权从一个对象手中移交到另一个对象手中，中间没有任何复制开销，也没有临时共享的中间态。
2.2 自定义删除器：从文件句柄到内存映射的通用管理
unique_ptr不只是用来管理堆对象的，它还可以管理任何"需要析构释放"的资源。这个能力来自模板的第二参数——删除器。默认删除器是std::default_delete<T>，负责delete T*；你也可以传自己的函数对象或lambda。我经常拿它管理文件句柄、套接字、内存映射。举个例子，如果我用fopen打开了一个文件，裸写法是记得fclose；但用unique_ptr包一层，把删除器设为[](FILE* f){ fclose(f); }，这个FILE*就自动会在作用域结束时关闭，包括异常路径下也一样执行。这一招的价值在于，你用同一种RAII模式统一了所有资源的生命周期管理，不再局限于new/delete。
需要留心：自定义删除器的类型会影响unique_ptr的占用空间。无状态的函数对象默认采用空基类优化，不会增加额外空间；但有状态的删除器会增大unique_ptr的体积。如果你的项目对内存布局敏感，比如要跨进程传输或者做紧凑型缓存，这个开销需要特别注意。另外，自定义删除器保存的是可调用对象，它本身也可能持有资源，这个复杂度的"嵌套"有时会让调试变麻烦，我的建议是能不用就不用，真需要的时候优先考虑lambda表达式。
3. shared_ptr的引用计数机制：从拷贝开销到控制块结构
说完独占所有权，我们来聊聊共享所有权。std::shared_ptr的设计目标是让多个智能指针共同拥有同一对象，当最后一个持有者销毁时，对象才被释放。我最早接触shared_ptr时，觉得它就是个加了引用计数的裸指针，后来真去翻实现才发现，问题没那么简单。shared_ptr并不只存储一个裸指针，它同时还要维护另一块数据——控制块。
控制块是shared_ptr性能成本和内存开销的主要来源。它一般包含强引用计数、弱引用计数、自定义删除器、分配器等信息。当你写std::shared_ptr<Foo> sp(new Foo);时，除了分配Foo对象本身的内存，还必须额外分配一块控制块内存。如果注意看，现在C++标准库都建议用std::make_shared来创建shared_ptr，原因很实在：make_shared把Foo对象和控制块放在同一次内存分配里，避免了两次独立分配的额外开销，也提高了缓存局部性。但是make_shared也不是万能的，后面我会说它的适用范围限制。
shared_ptr的拷贝语义极具迷惑性。拷贝一个shared_ptr，不是拷贝对象本身，而是让另一个shared_ptr也指向同一对象，同时控制块里的强引用计数加1。这个计数加1是原子操作，所以线程安全；但需要注意，原子计数只保证shared_ptr本身的安全，并不保证它所指向的对象在线程间访问是安全的。很多人看到"shared_ptr线程安全"的说法就误以为可以对共享对象并发读写，这是典型的认识盲区。我做个比喻：引用计数像一个门口的人数统计牌，系统只保证这个统计牌被正确更新，但它不负责保护屋子里的人。
我自己的项目中，shared_ptr用的最多的地方是配置管理和事件分发。配置对象创建后不会频繁变化，多个子系统都要读它，但又没有一个子系统能声称"这个配置归我所有"。用shared_ptr就很贴切：每个子系统保留一个副本，最后一个退出时自动释放配置。事件分发也是类似场景，多个订阅者同时收到同一事件对象，谁订阅谁持有，没人订阅了事件就析构。但这个机制里有一个我必须提醒的细节：引用计数是原子的，但控制块的分配和释放不是无代价的。高频遍历场景下，一次shared_ptr拷贝就有一次内存栅栏级别的开销，这种成本在普通任务里可忽略，但在千万级的循环里会被放大。
3.1 控制块为什么不能和对象分离
控制块里除了强引用计数，还有一个弱引用计数。这个弱引用计数不参与决定对象什么时候释放，但它决定了控制块本身能活多久。这个设计的原因是shared_ptr和weak_ptr都拿着同一个控制块的指针，控制块必须在所有相关指针都消失后才能释放。如果控制块提前跑了，weak_ptr就变成悬空指针。所以控制块真正的生命周期由强引用和弱引用共同决定：强引用归零时对象析构，弱引用也归零时控制块析构。
这个细节在我做某个缓存模块的时候踩过坑。当时我用unordered_map存了很多shared_ptr指向缓存对象，另外有一个管理器类维护所有weak_ptr作为观察者。对象被客户端指针持有，如果最后一次客户端释放后对象被回收，缓存应该自动移除对应的键。我原本以为weak_ptr过期就够了，但忘了控制块的释放时机。后来我想明白了：weak_ptr过期说明强引用为零，但管理器里还留着这些weak_ptr副本，它们会让控制块一直活着，控制块活着又保留着指针信息，导致缓存里的"过期条目"不会被清理。按这个机制，我需要定期手动检查weak_ptr是否过期并从容器里清理。这里要提醒大家：弱引用不延长对象生命周期，但会延长控制块生命周期，而控制块里存的那份对象指针信息会影响你的逻辑判断。
3.2 make_shared的适用范围和限制
推荐用make_shared几乎是现代C++的公认准则，但它确实有一个使用边界：当你的构造参数不匹配时，或者对象类型要求特殊对齐方式时，它就会显得不够灵活。make_shared首先要求你能用给定参数直接构造对象，如果你的类构造函数是私有的，或者你需要传递一个已被unique_ptr管理的对象整体转移进去，make_shared就可能派不上用场。
更重要的是内存释放时机的差异。用new+ 用shared_ptr构造的写法，对象内存和控制块内存是分开的；shared_ptr对对象最后一次强引用释放时，对象立即析构，但控制块要等弱引用清零后才释放，这意味着对象所占的内存被提早释放，而用make_shared时，对象和控制块连在同一块内存里，它只能把一整块内存留到最后控制块释放。这个差异对大部分程序没影响，但如果内存里有一个超大的对象，又配合着很多weak_ptr长期存活，用make_shared创建的对象可能比你以为的"晚得多"才归还给系统。反过来，对绝大多数短生命周期、弱引用比例低的场景，make_shared的效率优势非常明显，我建议毫不犹豫地默认使用它。
3.3 循环引用的本质和它引发的内存黑洞
共享所有权听起来完美，但一旦多个对象之间互相持有shared_ptr，就会形成循环引用。这是shared_ptr最著名的坑。循环引用的本质是引用计数无法归零：因为A持有B，B又持有A，两个引用各自都至少为1，编译器即使看到这两个对象已经完全不再被外部使用，也不会触发析构，内存就一直挂在那里。这个问题的可怕之处在于它不会像裸指针那样随时崩溃，而是像温水煮青蛙一样让内存慢慢上涨，最后程序无端卡死。
我印象最深的一个案例是一个图形节点系统。场景中有一个父节点Panel，它保存了所有子控件Node的shared_ptr；同时每个子控件Node内部又保存了它"归属的父节点"的shared_ptr，方便事件回调向上层传递。只要父节点和子节点互相持有，哪怕你已经从场景中移除整个Panel，这个树依然是自持的，永远不释放。这个bug表现很怪：项目里的对象明明"没了"，但内存占用一直涨。后来我逐个打印了各节点的引用计数，一眼看到两个计数都等于1才恍然大悟。
解决循环引用的正道是weak_ptr。它的设计意图就是：在A持有B的shared_ptr的同时，B只持有A的weak_ptr，这样B对A的引用不增加强引用计数，A可以在无人使用后正确释放。我们来看看weak_ptr更完整的用法。
4. weak_ptr如何拆掉shared_ptr之间的循环引用死锁
std::weak_ptr看起来像是shared_ptr的"弱化版本"，但它既不是真正的智能指针，也不能单独解引用。它更像一个"观察者"：它保存指向对象的非拥有型引用，不增加强引用计数，但能让你安全地检查对象还活着没。你要想访问对象，必须先借用一个shared_ptr副本。这个借用过程是通过lock()方法完成的，它返回一个临时的shared_ptr；如果对象已被释放，lock()返回空shared_ptr。
为什么weak_ptr要设计成"不能直接解引用"？这是出于安全的考虑。你拿着一把能开门但不能确保门后面的房间还存在的钥匙，如果直接开门进入，房间可能已经是废墟。weak_ptr就是要强迫你在每次访问前"检查房间是否还存在"——这个检查就是lock()。这个设计和shared_ptr的引用计数机制完美配合，为的是解决刚才说的循环引用问题，同时保证不会因为对象已释放而得到悬空指针。
拿前面图形节点的例子来说：Panel持有子节点Node的shared_ptr没问题，但Node保存"归属父节点"时应当使用weak_ptr。Node想向上层传消息时，先调用parent_.lock()，如果父节点还在就拿到了一个临时的shared_ptr，可以安全调用它的方法；如果父节点已经被移除并释放，lock()返回空指针，代码走"父节点不存在"的分支。这个方案的每一步都说得通：子节点不延长父节点生命周期，但能在父节点活着的时候使用它，也不怕父节点"中途消失"。
除了循环引用，weak_ptr还有一个被低估的应用场景：缓存和观察者模式。还是用我自己做的一个图像处理Demo来举例，当时我为每个图片对象建了一个缓存表，key是图片路径，value是对图片对象的weak_ptr。加载图片时才查找缓存，发现缓存里的weak_ptr还在，就通过lock()拿到现有对象，避免重复加载；如果lock()为空，说明图片已被清理，需要重新加载并刷新缓存为新的shared_ptr。这样缓存表本身不阻止图片对象释放，很大程度上避免了"缓存和业务对象的生命周期互相纠缠"的问题。
在线程池任务系统里weak_ptr也很好用。任务对象持有某个业务对象的weak_ptr，执行任务时先lock()，发现对象已经不在了，就直接跳过。这比shared_ptr传输参数安全得多，也比裸指针检查非空安全得多，因为裸指针非空不代表对象未析构。总结一下，weak_ptr的核心价值就是：让你能"参与"一个对象的生命周期，又不用"负责"它。
4.1 lock()的实现原理和性能代价
weak_ptr::lock()的实现逻辑可以理解成两步：先检查控制块的强引用计数是否为0，如果为0直接返回空shared_ptr；如果不为0，就尝试增加强引用计数，然后构造一个shared_ptr返回。这个"检查+增加"必须是原子操作，否则并发场景下可能出现：你检查的时候强引用计数是1，但紧接着另一个线程释放了最后一个shared_ptr，对象就析构了，你再增加计数就失灵了。标准库通过原子操作把检查与增加合并成一个原子步骤，保证了lock()要么得到持有对象的shared_ptr，要么得到空指针。
正因为lock()有原子操作和计数增加，它是有性能开销的。如果一个热点路径在每次访问对象时都调用lock()，频繁的原子操作会影响吞吐。我在某个高频事件回调里踩过这个坑：每个事件都lock()一次，实际测试发现锁竞争严重拖慢了整体处理速度。后来我在回调入口lock()一次得到shared_ptr，存到局部变量里，之后所有访问都用这个局部shared_ptr，把多次原子计数降低到一次，性能和正确性都保住了。这个做法本质上也是利用了shared_ptr拷贝计数成本低、生命周期长的特点。
4.2 enable_shared_from_this：获取this指针的安全姿势
处理weak_ptr时，一个伴随的小知识是enable_shared_from_this。有时候一个对象被shared_ptr管理着，它的某个成员函数需要获得指向自身的shared_ptr，然后用这个shared_ptr注册到别的管理器里去。直接用std::shared_ptr<T>(this)是非常危险的做法，因为这会凭空创建一个全新的控制块，导致同一个对象两个控制块，两个控制块分别计数，最后对象被释放两次。一个对象只有一个所有者，不能凭空再造一个所有者。
enable_shared_from_this提供了一种机制：继承了这个类后，对象内部会预埋一个weak_ptr，当对象第一次被某个shared_ptr管理时，这个weak_ptr就被初始化绑定到当前控制块。之后你可以安全调用shared_from_this()，它通过内部weak_ptr的lock()获得同一个控制块下的shared_ptr，不会产生新控制块，也不会多次释放。使用范围要注意：shared_from_this()必须在对象已经被shared_ptr管理之后调用，如果对象还是栈上对象或者裸指针，直接调用会抛出异常。我自己写过这种代码，在构造函数里想调用shared_from_this()，编译器不报错但运行时直接异常，原因就是对象还没进入任何shared_ptr的控制范围。
5. 项目实战中的选择准则：何时用哪种智能指针
讲了这么多，最后落到实操层面。我平时写代码时，对指针选型有个简单原则：默认用unique_ptr，除非你要共享所有权。这个准则听起来简单，但执行起来需要几个判断。先问自己一个问题：这个资源是否可能同时在多个地方被"拥有"？如果答案是"否"，unique_ptr就是最合适的选择，它既安全又高效，不会引入无谓的计数开销。如果答案是真的"是"，那么shared_ptr才是正确选项。
第二个问题是：如果你用了shared_ptr，是否形成了环？这时候要认真检查对象之间的引用关系。标准的检查姿势：画出对象依赖图，看从任何一个对象出发，沿着shared_ptr的箭头能不能走回自己。如果有环，break环的那条边应该改成weak_ptr。这个检查最好在设计阶段就做，等代码写完再重构会痛苦得多。
第三个问题是：接口边界怎么设计？我的习惯是：工厂函数返回unique_ptr；类构造函数只接收裸指针或引用参数，不在构造函数里持久化裸指针；类成员需要长期持有的资源用智能指针成员变量；如果某个API只使用对象而不需要拥有它，参数类型尽量用引用或裸指针（表示"我不拥有，只是借来用一下"）。这样类型本身就告诉我们所有权语义了。
关于性能，我整理一个我测过的粗略数据感受。单次unique_ptr的构造析构和裸指针几乎一样，它可以视为零开销抽象；shared_ptr的创建因为要分配控制块，比unique_ptr贵一些；shared_ptr的拷贝因为有原子计数，在高并发下会明显变慢。当时我在一个百万节点遍历的场景里，每访问一个节点就拷贝一次shared_ptr，实测比用引用版本慢了一倍多。后来把共享指针放在循环外，循环内只传引用，性能立刻回到正常水平。这里提醒大家：智能指针的语义正确性和它的性能特性要分开看，你不能只享受语义便利而不为其代价买单。
5.1 智能指针与裸指针混用时的边界管控
混用裸指针和智能指针几乎是无法避免的，因为有些老接口的封装就是裸指针。混用时最危险的写法是用裸指针再包一层shared_ptr或unique_ptr。比如你从某个地方拿到了一个裸指针，你并不知道它的来源是不是已经由别的智能指针管理，直接拿去构造一个shared_ptr就会导致两个控制块，到时候同块内存被释放两次。处理这种情况唯一的安全办法是：明确裸指针只代表"观察资格"，不要用它去构建所有权管理对象。
反过来，如果某个函数要返回裸指针，但它实际是从一个unique_ptr成员里获取的，你需要先明确：返回的裸指针是让调用方临时使用的，调用方绝不能delete。我通常会在接口命名上带出这个语义，比如函数名以View/Fetch开头，同时注释说明"只读借用，不转移所有权"。接口层面的混用最忌讳的就是默认"裸指针所有权归调用方"，因为一旦形成这个习惯，整个项目的所有权边界立刻变模糊。
5.2 那些适合保留裸指针的场景
虽然本文推荐优先用智能指针，但裸指针并没有完全过时，某些场景下它反而是正确的选择。比如非拥有型的参数传递，你只想着临时看一眼对象的成员，完全不想影响它的生命周期，这时候用裸指针或引用比shared_ptr更轻量。还有像自绘UI的后端接口，一次回调里传过来的对象生命周期由框架保证，你在函数内部只需要同步读取，起一个裸指针参数完全合理。另外，当你需要在性能极端敏感的路径里做访问，智能指针的解引用和计数的确会有额外影响，裸指针+契约式管理也许更合适。
说实话，判断什么时候用裸指针，标准不是"这个代码够不够现代"，而是"所有权边界是否足够清晰"。如果某种接口的调用方和被调用方在同一个模块内、生命周期约定非常明确，裸指针不会引起歧义；一旦涉及跨模块、跨线程、长期存储，裸指针的隐患就会放大。我见过朋友维护的老项目里，一个接一个地用裸指针做成员变量，最后析构函数里要一一检查是否为空、是否需要delete，这种痛苦我自己深有体会。
5.3 从老代码迁移到现代智能指针的低风险改造路径
如果你现在接手的是C++98或早期C++11风格的老项目，直接全面替换智能指针风险极大。我的经验是分步骤走。第一步，把那些在异常安全性上明显有问题的裸指针替换成unique_ptr，重点看工厂函数和类成员；第二步，把需要共享的缓存和事件对象改用shared_ptr，并排查循环引用；第三步是引入weak_ptr做观察者引用，这一步要仔细梳理依赖关系；最后才是把接口层的所有权语义统一起来，这个阶段往往要改头文件签名，牵连较广。
一个特别值得注意的坑是，老项目里很多裸指针指向的是栈对象或者静态对象，这时候用unique_ptr包裹并delete一定是灾难。改造之前必须确认指针指向的是堆对象。我记得有个同事把模块里一个指向线程局部对象的裸指针换成了unique_ptr，结果程序在退出时把所有线程都崩了一次。这种问题不是智能指针本身有毛病，而是迁移时没有仔细核对底层对象的归属。所有替换动作之前，俯下身去看每处指针的来源和流向，别被"带智能指针就一定安全"的错觉误导。
在我自己写代码的过程中，我慢慢地形成了一种判断习惯：每写下一个指针类型的签名，都先问自己一句"这个对象谁创建、谁持有、谁销毁？"如果答不出来，这个设计本身就有问题，不管用什么指针都会埋雷。智能指针帮你把答案固化到类型系统里，而不是让这段关系分散在代码注释和口头交代中。希望读到这篇的朋友，能在自己的项目里也体会一下这种"所有权明确"带来的踏实感，那是一种不用整天惦记着"我忘记释放了吗"的自由。
