UE5 MakeShareable 与 TRawPtrProxy：裸指针所有权转移机制拆解

如果你用 UE5 写过一阵子 C++，大概率已经见过 MakeShareable 了，尤其是处理从 C 风格接口、第三方原生库或者旧模块手里接过来的裸指针时。绝大多数教程只会告诉你“用 MakeShareable 把裸指针包成 TSharedPtr”，但当你真去翻引擎头文件里的源码注释，会发现它真正的返回类型其实是 SharedPointerInternals::TRawPtrProxy<T>，一个很多开发者听都没听过的类型。

这篇笔记就顺着引擎源码注释的线索走一遍：MakeShareable 返回的 TRawPtrProxy<T> 到底是什么、TSharedPtr 和 TSharedRef 的构造函数为什么要去消费这个临时代理、引用控制器是在哪一步创建的、以及实践里最容易踩的几个坑。我把它写成一份“源码注释大纲式”的拆解，适合那些已经会基本用 TSharedPtr，但还想把智能指针底层机制彻底搞明白的人。

1. MakeShareable 到底解决什么问题

1.1 从“接管裸指针”说起

在 UE5 的 C++ 环境里，能被 GC 管的是 UObject，而绝大多数普通 C++ 对象只能用 new 创建。这类对象一旦指针被传来传去，很容易出现两件事：要么没人 delete 导致泄漏，要么两个模块同时 delete 导致崩溃。TSharedPtr 就是来解决这个问题的，它用引用计数保证对象在最后一个持有者放手时才被释放。

但这里有个微妙的地方：TSharedPtr 本身不会凭空知道一个裸指针该不该由它接管。比如你从某个原生库拿回来一个 FNativeHandle*，你到底是只想临时看一眼，还是想把这个指针的生命周期彻底交给智能指针？这必须有一种表达方式。MakeShareable 干的事就是交托所有权，语义非常明确：这个裸指针从现在开始归智能指针管，原来的调用方不要再手动 delete。

cpp复制class FMyData
{
public:
    int32 Value = 0;
};

// 场景：某个旧接口返回了裸指针，现在你要接管它
void TakeOverExample()
{
    FMyData* RawData = new FMyData();
    RawData->Value = 42;

    TSharedPtr<FMyData> DataPtr = MakeShareable(RawData);

    // 从这行之后，绝对不能再写 delete RawData
}

这种“把所有权决定权显式表达出来”的设计，正是 MakeShareable 存在的理由。它不是一个花哨的工具，而是一道明确区分“观察”和“拥有”的分界线。

1.2 MakeShareable 与 MakeShared 怎么选

很多新手会把 MakeShareable 和 MakeShared 混在一起，以为只是写法不同。实际上它们差距很大，选错会直接影响性能和代码结构。

cpp复制// 方案 A：先有对象，再接管所有权
FMyData* Raw = new FMyData();
TSharedPtr<FMyData> PtrA = MakeShareable(Raw);

// 方案 B：原地创建对象并交给智能指针
TSharedPtr<FMyData> PtrB = MakeShared<FMyData>();

引擎官方推荐优先使用 MakeShared，原因很直接：少一次内存分配，对象和引用计数紧挨着，访问计数时的缓存命中率更高。但实际项目里经常遇到“对象已经存在”的情况，比如模块 A 从 C 库拿到一个裸指针要交给模块 B 托管，这时候只有 MakeShareable 能接住。

1.3 什么场景非用 MakeShareable 不可

我总结了几类必须走 MakeShareable 的典型场景。

第一类是外部库返回值。引擎插件里如果接了原生 C/C++ 库，库内部用 new 创建对象，通过句柄或裸指针返回，这时你想把它纳入智能指针体系，只能通过 MakeShareable。

第二类是条件初始化。某些对象需要先经过复杂的计算、查表或者尝试创建，失败后可能返回另一个备用对象，这种情况下没法用 MakeShared 一次搞定，只能在对象创建完成后用 MakeShareable 接管。

cpp复制TSharedPtr<FConfigEntry> LoadOrCreateEntry(const FString& Key)
{
    FConfigEntry* Entry = FindFromCache(Key);
    if (!Entry)
    {
        Entry = new FConfigEntry();
        Entry->Key = Key;
    }
    return MakeShareable(Entry);
}

第三类是对象所有权本来就在你手里，但需要跨模块传递。比如一个异步任务完成后，把结果对象“送”给主线程逻辑，用 MakeShareable 包裹后再传出去，接收方拿到的 TSharedPtr 就拥有了合法所有权，不用担心谁去释放。

2. TRawPtrProxy 到底是干嘛的

2.1 还原 TRawPtrProxy 的核心实现

先说结论：TRawPtrProxy 是一个非常薄的临时对象包裹器，内部基本就是一个裸指针。按照引擎源码的注释结构，可以还原成下面这样，注意它只是结构示意，不是逐字源码：

cpp复制// 源码位置：Runtime/Core/Public/Templates/SharedPointer.h
namespace SharedPointerInternals
{
    /**
     * TRawPtrProxy 是 MakeShareable 的返回类型。
     * 它不真正拥有对象所有权，也不参与引用计数。
     * 它只负责把一个裸指针安全地传递给 TSharedPtr / TSharedRef 构造函数。
     */
    template <typename T>
    struct TRawPtrProxy
    {
        T* Object = nullptr;

        explicit TRawPtrProxy(T* InObject)
            : Object(InObject)
        {
        }
    };
}

MakeShareable 的完整实现也很短：

cpp复制template <typename T>
SharedPointerInternals::TRawPtrProxy<T> MakeShareable(T* InObject)
{
    return SharedPointerInternals::TRawPtrProxy<T>(InObject);
}

没错，MakeShareable 没有创建任何引用计数控制块，它只是把裸指针打包成一个临时对象。真正创建控制器、初始化计数的是 TSharedPtr 或 TSharedRef 的构造函数。

看到这里你可能会问：既然 MakeShareable 什么都不做，为什么不直接返回 TSharedPtr<T>？这个问题的答案就是 TRawPtrProxy 存在的核心价值。

2.2 用临时代理标记所有权意图

如果 TSharedPtr 的构造函数直接接受裸指针 T*，会带来一个语义灾难：任何裸指针都能隐式变成共享指针，编译器完全无法判断你到底是“接管所有权”还是“临时借用”。更麻烦的是，构造函数重载会变得非常容易冲突。

举个例子，如果允许这样写：

cpp复制TSharedPtr<FMyData> Ptr = RawData;

那么当 RawData 为空指针时，或者当某个函数同时有 TSharedPtr<FMyData> 和 FMyData* 两个重载时，调用方和阅读者都会一头雾水。所有权归属不明确，代码一旦复杂起来，就等于给自己埋雷。

TRawPtrProxy 解决这个问题的思路叫“标签分发”。代理对象本身没有业务逻辑，它就像一个贴着“接管所有权”标签的信封，编译器看到这个类型就能确认：调用方明确地把裸指针交了出来，TSharedPtr 可以放心地创建引用计数控制器。

这是 C++ 模板元编程里很常见的手法：靠类型来传递语义，而不是靠文档和自觉。UE 引擎内部大量使用这类“代理构造对象”，理解了 TRawPtrProxy，再看其它 Proxy 类型会容易得多。

2.3 TSharedPtr 和 TSharedRef 是怎么消费代理的

TSharedPtr 和 TSharedRef 的构造函数有专门的接收 TRawPtrProxy 的重载。我简化后的逻辑如下：

cpp复制// 极简示意，省略了 Offset 和异常安全处理
template <typename OtherType, ESPMode Mode>
TSharedPtr(const SharedPointerInternals::TRawPtrProxy<OtherType>& InProxy)
{
    // 1. 取出代理中的裸指针
    OtherType* RawObject = InProxy.Object;

    // 2. 创建引用控制器，初始的强引用计数为 1
    Controller = new SharedPointerInternals::TReferenceControllerWithSharedPtr<OtherType>(RawObject);

    // 3. 保存对象指针
    Object = RawObject;
}

TSharedRef 的构造逻辑类似，但它有一个额外动作：检查传入的裸指针不能为空。因为 TSharedRef 是“必定有效的共享引用”，不允许持有空对象。

cpp复制template <typename OtherType, ESPMode Mode>
TSharedRef(const SharedPointerInternals::TRawPtrProxy<OtherType>& InProxy)
{
    // TSharedRef 不接受空对象，传空会直接触发 check
    check(InProxy.Object != nullptr);

    // 然后创建控制器并接管所有权
}

这里就体现出代理类型的另一个好处：因为 MakeShareable 返回的是临时对象，编译器能严格区分出“从代理构造”和“从已有共享指针复制”两条路径，不会把拷贝构造和接管构造搅在一起。

顺带说一句，TWeakPtr 通常不直接从 TRawPtrProxy 构造，它的主要入口是 TSharedPtr / TSharedRef 的复制。所以在一般情况下，你不需要给 TWeakPtr 传 MakeShareable 的结果，直接从共享指针复制就行。

3. 从调用行到引用控制器创建

3.1 完整链路拆解

现在我们把一行最普通的代码展开，看看里面到底发生了什么：

cpp复制TSharedPtr<FMyData> Ptr = MakeShareable(new FMyData());

这行代码的实际执行链条是：

第一步，new FMyData() 在堆上创建对象，得到一个裸指针。

第二步，MakeShareable 收到这个裸指针，创建 TRawPtrProxy<FMyData> 临时对象，保存指针。这一步不做任何内存分配，只是简单的指针搬运。

第三步，TSharedPtr<FMyData> 的构造函数接收临时代理对象。构造函数内部发现这是接管所有权的请求，于是去堆上创建一个引用控制器对象，并让初始强引用计数等于 1。控制器的构造函数里会保存对象指针，以及设置默认删除器。

第四步，TSharedPtr 把自己内部的 Object 指针和 Controller 指针都初始化好。此时临时代理对象的生命周期结束，析构函数什么都不释放。

第五步，如果编译器应用了返回值优化，临时代理对象甚至可能被完全优化掉，整个过程只留下一次对象分配和一次控制器分配。

用代码来表达就是：

cpp复制// 构造控制器时要做的事
Controller->Object = RawObject;
Controller->ReferenceCount = 1;
Controller->WeakReferenceCount = 1;

注意，这里的弱引用计数也从 1 开始，是因为控制器自身需要持有一个弱引用观察位，用来判断是否能在对象被删除后安全自毁。

3.2 引用控制器里到底存了什么

UE 的引用控制器实际上是个类层级，根据控制对象是否需要支持弱指针，会有不同的派生类。核心字段可以简化为下面这些：

cpp复制template <typename T>
class TReferenceControllerBase
{
public:
    T* Object;            // 被管理的对象指针
    int32 ReferenceCount; // 强引用计数：TSharedPtr + TSharedRef
    int32 WeakReferenceCount; // 弱引用计数：TWeakPtr 的观察者数量
};

强引用计数决定对象什么时候被删除。每复制一次 TSharedPtr，强引用计数就加 1；每析构一个 TSharedPtr，强引用计数就减 1。当数值减到 0，控制器的删除逻辑就被触发，调用默认的 delete 释放对象。

弱引用计数则决定控制器本身什么时候被销毁。就算对象已经被删除，只要还有 TWeakPtr 在观察，控制器就不能立刻释放，因为弱指针还要靠控制器里的信息判断对象是否还活着。当弱引用计数也归零，控制器才会真正销毁。

这种双计数设计，本质上是把“对象生命周期”和“观察者信息生命周期”分开了。对象可以死得干净利落，但观察者还能知道“这对象死过了”，不至于拿着一个野指针继续访问。

3.3 引用计数归零后的析构链

为了把流程说透，我写了一个极简的模拟场景：

cpp复制TSharedPtr<FMyData> Ptr = MakeShareable(new FMyData());

{
    TSharedPtr<FMyData> Copy = Ptr; // 计数从 1 变 2
} // Copy 析构，计数从 2 变 1

Ptr.Reset(); // 计数从 1 变 0，触发对象删除

在 Reset() 这一行，强引用计数归零，控制器调用删除器销毁 FMyData 对象，同时弱引用计数减 1，从 1 变 0，控制器随即自我释放。两条链一次性走完。

但如果你这个时候还有一个弱指针在观察：

cpp复制TSharedPtr<FMyData> Ptr = MakeShareable(new FMyData());
TWeakPtr<FMyData> Weak = Ptr;

Ptr.Reset(); // 对象被删除，但控制器还活着
// 此时 Weak.IsValid() == false，Weak.Lock() 返回空 TSharedPtr

对象已经释放，但控制器因为弱引用计数不为零而继续存在。TWeakPtr 查询时发现 Object == nullptr，就知道对象已经没了。这个机制保证你永远不会从一个已经失效的弱指针里拿到野指针。

4. 实操中那些绕不开的坑

4.1 同一个裸指针被 MakeShareable 两次

这是我在实际项目里见过最典型的崩溃原因，没有之一。

cpp复制FMyData* Raw = new FMyData();

TSharedPtr<FMyData> A = MakeShareable(Raw);
TSharedPtr<FMyData> B = MakeShareable(Raw); // 大坑

看起来 A 和 B 都指向同一个对象，逻辑上好像没什么问题。但实际上，两次 MakeShareable 会创建两个完全独立的引用控制器，每个控制器的强引用计数都从 1 开始。A 析构时，第一个控制器认为计数归零，于是 delete 一次 Raw。B 析构时，第二个控制器也认为计数归零，又 delete 一次 Raw。两次 delete 同一个对象，轻则内存损坏，重则直接崩溃。

正确做法是让第二个共享指针从第一个复制而来：

cpp复制FMyData* Raw = new FMyData();

TSharedPtr<FMyData> A = MakeShareable(Raw);
TSharedPtr<FMyData> B = A; // B 与 A 共享同一个控制器

或者干脆复制完就把 A 重置，总之，任何已经由智能指针接管所有权的裸指针，都不应该再次被 MakeShareable 接管。

提示：尽量形成习惯，凡是调用 MakeShareable 的代码行，都看作“所有权转移点”。这个点上只允许一个接收方。

4.2 UObject 严禁 MakeShareable

MakeShareable 面对 UObject 时有一个更阴间的坑。

UObject 的生命周期由引擎的 GC 系统管理，你根本不应该手动 delete。如果你对 UObject 调用 MakeShareable，等于让引用计数控制器也参与管理同一个对象，两套生命周期机制同时作用在一个对象上，释放时机稍微一错位，GC 和控制器就会互相踩踏。

cpp复制// 错误示例：不要对 UObject 使用 MakeShareable
UObject* Obj = NewObject<UObject>();
TSharedPtr<UObject> BadPtr = MakeShareable(Obj);

不同引擎版本里，这种用法可能触发静态断言报错，也可能只是运行时表现出诡异行为。无论哪种，结论都一样：UObject 请用 UPROPERTY、TStrongObjectPtr 或者普通的 TWeakObjectPtr，不要硬塞给 TSharedPtr。

这里的根本原因是设计定位不同：TSharedPtr 面向非 GC 的普通 C++ 对象，UObject 面向引擎自带的反射和 GC 体系。再强的引用计数也救不了根本不适配的对象类型。

4.3 自定义删除器怎么办

MakeShareable 这个名字容易让人产生误解，以为它能把任何指针变成共享指针。但它其实只管所有权接管，删除器永远是默认的 delete。

如果对象来自自定义内存池，或者释放时需要挂到某个管理器上，MakeShareable 就不够用了。引擎源码里更底层还有带删除器参数的构造路径，那些构造会接收一个自定义 deleter，在引用计数归零时调用你的释放逻辑。

我建议你记住一条原则：MakeShareable 只适合“普通堆对象，常规 delete 释放”的场景。如果你的对象来自对象池、共享内存或者需要特殊释放钩子，老老实实下探到更底层的构造接口，别硬用 MakeShareable。

4.4 线程安全模式要不要换

UE5 里 TSharedPtr<T> 默认是 ESPMode::ThreadSafe，引用计数的加减走原子操作。原子操作有性能成本，但换来的是多个线程同时复制、析构共享指针时的安全性。

如果你的数据严格只在单线程内传递，可以显式指定 ESPMode::NotThreadSafe：

cpp复制TSharedPtr<FMyData, ESPMode::NotThreadSafe> SingleThreadPtr;

这个模式下的引用计数是普通 int32，性能更好，但一旦跨线程使用就是未定义行为，调试起来非常痛苦。从我接触到的项目看，绝大多数场景用默认的线程安全模式就够了，不要为了那一点点计数开销牺牲排查难度。等你用性能分析工具确实证明这里是热点，再考虑换也不迟。

5. 照着注释读源码的正确姿势

5.1 从哪里读起

如果你想把今天聊的东西亲手验证一遍，最直接的办法就是打开引擎源码里的 Runtime/Core/Public/Templates/SharedPointer.h。

这个文件是 UE 智能指针的核心，内容很长，但不要从头硬啃。我建议顺着三条主线走：

第一条线是 MakeShareable 和 TRawPtrProxy，这条线能帮你理解“所有权接管”。第二条线是 TSharedPtr 的构造函数和 Reset、Get、IsValid 这几个核心函数，理解引用计数怎么变化。第三条线是 TReferenceController 相关类型，理解控制器如何驱动对象释放。

每一行注释都是一个线索。引擎作者在关键类型上方写下的注释，通常直接告诉你这个类存在的理由，比如“这个代理类型让构造函数能够区分所有权语义”。读到这类注释时，停下来想一想，如果没有这个类型，代码会变成什么样，收获会比一路扫读大得多。

5.2 一份现成的“注释大纲”范本

为了方便阅读源码头文件时有个地图，我把今天拆解的内容整理成一份注释大纲，你可以把它当作理解 MakeShareable 的主线：

code复制MakeShareable(InObject)
├─ 参数：InObject —— 要被接管所有权的裸指针
├─ 返回类型：TRawPtrProxy<T>
│   ├─ 极薄的临时对象
│   ├─ 不持有所有权
│   ├─ 不参与引用计数
│   └─ 只携带 Object 指针，供构造函数消费
├─ 消费方：TSharedPtr / TSharedRef 构造函数
│   ├─ 取出代理中的裸指针
│   ├─ 创建引用控制器
│   ├─ 初始化强引用计数为 1
│   └─ 保存 Object 与 Controller
└─ 运行时生命周期
    ├─ 强引用计数 > 0，对象存活
    ├─ 强引用计数归零，对象被删除
    └─ 弱引用计数归零，控制器销毁

带着这张图去读源码，你会发现文件里那些分散的类、模板参数、重载构造函数，其实都围绕着同一个核心逻辑组织起来：谁持有对象，谁观察对象，谁决定对象的死亡。

5.3 验证理解的三个小实验

光读不练容易形成错觉，我给你留三个可以快速验证的小实验。

实验一，复制观察计数。创建一个 TSharedPtr，打印它的 GetSharedReferenceCount()，然后复制一份再打印，观察计数从 1 变 2，析构后回到 1。这样一个动作就能让你直观感受引用计数的增减。

实验二，验证弱指针残留。创建一个共享指针，再从它复制出一个弱指针，然后 Reset() 共享指针。你会发现 Weak.IsValid() 返回 false，但整个程序不会崩溃。这就证明了控制器还活着，只是对象已经释放。

实验三，故意触发双重接管。对一个裸指针连续调用两次 MakeShareable，分别交给两个共享指针，然后让两个指针都离开作用域。大概率会崩溃或触发断言。崩溃位置能帮你反向定位到代码里的“所有权转移点”，从此对这个坑的印象会非常深。

这三个实验都不需要复杂工程配置，一个空关卡加少量代码就行。全部做下来，你对 MakeShareable 和 TRawPtrProxy 的理解会从“会用了”变成“知道为什么了”。

最后再分享一点个人体会：MakeShareable 最大的价值不是“把裸指针包进智能指针”这个动作本身，而是它用 TRawPtrProxy 这个临时代理，把所有权意图变成类型系统里看得见、查得着的东西。我踩过几次双重接管的坑之后才真正明白，源码里这种“用类型表达意图”的设计，比任何注释都更能防止你犯低级错误。以后你只要看到返回值是某个 Proxy 的全局函数，就该意识到这里八成是一个所有权转移点，处理时要格外小心。