UE5智能指针源码深剖：MakeShareable与TRawPtrProxy的构造秘密

做 UE 开发这几年，我养成了一个习惯：遇到诡异的崩溃，先不急着搜答案，而是把相关源码的头文件注释从头读一遍。UE 的源码注释确实写得有体系，尤其是 SharedPointer.h 前面的那一段“智能指针设计大纲”，几乎把整个 TSharedPtr / TSharedRef / TWeakPtr 家族的设计动机和使用规则都讲透了。今天这篇系列笔记（48-2）就顺着 MakeShareable 这个全局函数，以及它背后那个看起来没头没尾的 SharedPointerInternals::TRawPtrProxy<T> 模板类，把 UE 智能指针的内部机制完整盘一遍。

很多新人看 MakeShareable 只记着“把裸指针变成共享指针”，至于它内部经过哪几层构造、为什么返回 TSharedRef 而不用 TSharedPtr、TRawPtrProxy 这个代理类型到底干的什么活，基本没概念。结果代码能跑，但一遇到生命周期问题就抓瞎。这篇文章适合那些已经在 UE5 里写过 C++ 代码、但还没系统读过智能指针源码的开发者。读完你至少能回答三个问题：MakeShareable 的所有权转移意味着什么、TRawPtrProxy 为什么存在、以及 UE 智能指针的注释大纲帮你避开了哪些坑。

1. 为什么会有人盯着 MakeShareable 研究：裸指针失控现场与智能指针家谱

1.1 一个典型的悬挂指针崩溃现场

先还原一个我调试过多日的场景。项目里有个资源管理模块，内部维护一张资源表。某个业务逻辑从资源管理模块拿到一个裸指针，缓存起来，等待异步回调时再访问：

cpp复制UObject* CachedResource = ResourceManager->GetResource(TEXT("Enemy_CH0601"));

AsyncTask(ENamedThreads::AnyBackgroundThreadNormalTask, [CachedResource]()
{
    // 这里访问 CachedResource
    CachedResource->SomeFunction();
});

如果资源管理模块在后台某个时刻把资源释放了，回调里访问的就是悬挂指针。这种崩溃随机性极强：Debug 配置下可能表现在访问已释放内存，Release 配置下可能直接读出脏数据，偶尔还会触发内存保护异常。更麻烦的是，崩溃堆栈往往指向业务代码而不是释放代码，查起来相当费劲。

我当时加了一堆判空 if (CachedResource)，完全没用——悬挂指针本身非空，只是指向的对象已经没了。真正有效的做法是把裸指针换成共享所有权智能指针，让生命周期跟着引用计数走。这也是 MakeShareable 被设计出来的典型场景：你从外部拿到一个裸指针，需要把它接入共享所有权体系。

1.2 UE 智能指针家谱一览

UE 的智能指针家族一共五个主要成员，整整齐齐放在 SharedPointer.h 里，它们共享一套引用计数基础设施。我用表格梳理一下：

每个类型都有应用场景，不是随便选。TSharedRef 传递“这个对象一定存在”的契约，函数参数如果用 TSharedRef 接收，调用方在编译阶段就必须保证给个有效引用，这比运行时判空更早暴露问题。TWeakPtr 则用于那些“我可能要观察你，但我不想替你续命”的场景。等你读 SharedPointer.h 的注释大纲时会发现，官方对每个类型的使用边界写得很清楚，根本不用自己瞎猜。

1.3 MakeShareable 在这个家谱里的位置

MakeShareable 不是类，是定义在 SharedPointer.h 里的全局模板函数，专门负责“从裸指针创建 TSharedRef”。它不分配对象内存，也不拷贝对象，而是通过内部机制把裸指针的所有权转移给引用计数控制器。

一定要把它和 MakeShared 区分开：MakeShared 是从无到有创建对象，能一次性分配对象和控制块，性能更好；MakeShareable 是接管一个已经存在的裸指针，用于第三方接口、反射系统、旧模块回调等场景。理解这个差异，是后续正确使用的前提。

2. 源码拆解：从 MakeShareable 到 TRawPtrProxy 的构造链路

2.1 MakeShareable 的函数签名到底长什么样

在 UE5 源码中，MakeShareable 的简化版本大致是这样：

cpp复制template <typename T, ESPMode Mode = ESPMode::ThreadSafe>
TSharedRef<T, Mode> MakeShareable(T* InObject)
{
    return TSharedRef<T, Mode>(
        SharedPointerInternals::TRawPtrProxy<T, Mode>(InObject)
    );
}

两个关键信息立刻值得关注。

第一，返回类型是 TSharedRef<T> 而不是 TSharedPtr<T>。这表示 MakeShareable 产出的引用保证非空。传入裸指针非空，创建出来的 TSharedRef 就一定有效；如果调用方需要可空版本，可以再用 TSharedPtr<T> 从 TSharedRef 构造。官方把“创建”和“是否可空”做成两个类型，是为了在编译期强制非空引用不可被赋值成空，避免运行时判空到处散落。

第二，参数是 T* InObject 按值传入。函数不关心这个指针从哪里来，但从这个函数返回开始，裸指针背后的内存就归引用计数控制器了。这个语义在源码注释里被反复强调过，一定要刻在脑子里。

2.2 TRawPtrProxy：一个极简但不可缺的“类型标记”

TRawPtrProxy 定义在 SharedPointerInternals 命名空间中，代码量极其少：

cpp复制namespace SharedPointerInternals
{
    template <typename T, ESPMode Mode = ESPMode::ThreadSafe>
    struct TRawPtrProxy
    {
        T* Object;

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

就这么一个只有构造函数的极简结构体，它存在的核心动机是：类型标记。为什么不能直接把 T* 传入 TSharedRef 构造函数？因为 TSharedRef 有一系列构造函数重载，包括复制构造、从 TSharedPtr 构造、从 TWeakPtr 构造。如果允许裸指针直接参与重载决议，编译器在面对 TSharedRef<FThing> Ref(somePtr) 时就无法确定调用方意图——到底是要新建一个引用计数控制块，还是把别的引用结果再包一层？

TRawPtrProxy 把裸指针包了一层，为编译器给出了明确信号：这是“一个待接管的原始指针”，请走【裸指针 -> 新引用控制块 -> 共享引用】这条路径。它不携带任何业务方法，但它的类型本身就包含了语义。用生活类比解释：这就像一个房屋过户代办。房子还是那个房子，你拿到钥匙（裸指针）不能直接住，得通过中介（TRawPtrProxy）完成所有权登记。登记完毕后，买家手里那张房产证（TSharedRef）才能真正代表房子归他管，后续的存续也由房产中心（引用计数控制器）负责。

2.3 从裸指针到 TSharedRef 的完整构造链路

把整个调用链展开，一共有六步：

1. 调用方执行 MakeShareable(RawPtr)。
2. 函数内部构造 SharedPointerInternals::TRawPtrProxy<T>(RawPtr)。
3. TSharedRef 构造函数接收这个 Proxy，取出其中的 T*。
4. 构造函数使用该指针 new 出一个引用计数控制块 TReferenceControllerBase<Mode>，控制块持有对象指针和引用计数。
5. 控制块把初始引用计数置为 1，表示当前有一个 TSharedRef 持有它。
6. TSharedRef 内部保存两个指针：对象指针和控制器指针，返回给调用方。

从这层设计看，TSharedRef 内部其实存的是两个指针，而不是一个。当新的 TSharedRef 从已有 TSharedRef 复制构造时，它复制对象指针和控制器指针，同时对控制器的引用计数执行 +1；析构时执行 -1，减到 0 才真正销毁对象和控制器。

cpp复制// 简化伪代码，展示 TSharedRef 内部构造逻辑
template <typename T>
TSharedRef<T>::TSharedRef(SharedPointerInternals::TRawPtrProxy<T> InProxy)
    : Object(InProxy.Object)
    , SharedReference(AllocateController(InProxy.Object))
{
    // 引用计数已初始化为 1
}

控制器类型 TReferenceControllerBase<Mode> 还有一个派生体系，核心差异在于引用计数用什么实现：ThreadSafe 模式用原子计数器，NotThreadSafe 模式用普通整型。这个选择直接决定跨线程传递是否安全，后面我会专门讲。

2.4 所有权转移：最容易被忽略但绝对不能违背的规则

MakeShareable 不拷贝对象，它转移所有权。具体表现在三条硬规则：

• 传入的裸指针所属内存在智能指针诞生后，由引用计数机制负责释放。
• 调用方绝对不能再对原裸指针调用 delete。
• 调用方最好立刻把裸指针置空，防止后续误用：

cpp复制FMyData* Raw = new FMyData();
TSharedRef<FMyData> Ref = MakeShareable(Raw);
Raw = nullptr; // 立刻断掉裸指针源头

这条规则的底层原因是：控制块记录了对象地址，引用计数归零时它会执行 delete Object。如果你在外面又 delete 了一次，同一块内存被释放两次，轻则崩溃，重则堆损坏。官方注释大纲里把这条列为头号警告，我后续排查的崩溃案例中，至少有三次是源自这个原因。

3. 精读 SharedPointer.h 的注释大纲：30 分钟掌握 UE 智能指针设计意图

3.1 头文件注释到底写了哪些内容

SharedPointer.h 文件顶部有一段很长的英文注释，浓缩了 UE 智能指针的设计指导思想。我按自己的理解把核心条目翻译成工程语言：

第一，为什么需要智能指针管 C++ 对象。UE 的编辑器、游戏逻辑层大量使用 C++ 对象，但这些对象在异步任务、多线程、编辑器热重载场景下的生命周期非常难跟踪。裸指针加手动 delete 的方式在纯游戏循环里还能跑，一旦模块化、插件化、异步化，立刻失控。引用计数智能指针提供确定性的生命周期管理，既不依赖 GC 的延迟回收，也不依赖开发者手动释放的自觉。

第二，什么时候选哪种指针。注释明确区分了 TSharedPtr（需要判空，表示可能缺失）、TSharedRef（非空引用，表示一定存在）、TWeakPtr（观察者，不增加引用计数）。它特别提醒：能在编译期用 TSharedRef 表示非空的地方，就不要退化成 TSharedPtr 加运行时判空，类型本身就能约束意图。

第三，线程安全模型。默认的 ESPMode::ThreadSafe 使用原子操作维护引用计数，允许同一个共享对象被多个线程同时引用和释放。ESPMode::NotThreadSafe 用于确定不跨线程的场合，省掉原子操作开销。这是 UE 智能指针和标准库 std::shared_ptr 的一个显著风格差异：UE 在类型模板参数层面就暴露线程模型，而不是完全由实现细节决定。

第四，循环引用警告。两个 TSharedPtr 互相持有，引用计数永远无法降到 0，内存泄漏无声无息。官方建议把其中一个方向改成 TWeakPtr。

第五，与标准库 std::shared_ptr 的差异。UE 智能指针不支持管理数组、不支持别名构造、没有 weak_from_this()；TSharedFromThis 和标准库的 enable_shared_from_this 语义也不完全一样，使用时必须确认对象确实是通过智能指针持有的。

这五条基本就是官方注释大纲的骨架。读明白了，你对 UE 智能指针“能做什么、不能做什么”就建立起完整认知了。

3.2 注释和 TRawPtrProxy 的对应关系

把注释大纲和源码实现对应起来，很有意思。

“所有权转移”在注释里是规则，在实现里就是 TRawPtrProxy 接管裸指针的行为。控制块持有了对象地址，所有权从此属于引用计数系统，不再属于调用方。

“线程安全模型”在注释里是选项，在实现里就是 Mode 模板参数贯穿始终。TRawPtrProxy<T, Mode> 里的 Mode 最终决定 TReferenceControllerBase<Mode> 用的是 FThreadSafeCounter 还是普通 int32。如果你试图用一个 ThreadSafe 的 TSharedRef 去接管一个用了 NotThreadSafe 控制块的对象，编译器会在类型层面拦下不匹配，这又是类型系统在起作用。

3.3 容易被忽略的 TSharedFromThis 说明

注释里还专门讲了 TSharedFromThis，它是为了让对象在自身方法内部拿到指向自己的 TSharedRef：

cpp复制class FNode : public TSharedFromThis<FNode>
{
public:
    TSharedRef<FNode> GetSelf() { return AsShared(); }
};

注意，使用 TSharedFromThis 有个前置条件：对象必须是通过智能指针创建并持有的。如果对象在栈上创建，调用 AsShared() 会触发断言或异常，因为内部拿不到控制块。这个细节如果没读注释，踩到一次就很困惑。

4. 实操环节：在 UE5 工程中安全使用 MakeShareable 的完整姿势

4.1 最小可用代码与生命周期验证

在 UE5 的任何函数内部，写这样一段代码就能跑通整个流程：

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

void SomeFunc()
{
    FDataBlock* Raw = new FDataBlock();
    Raw->Value = 42;

    TSharedRef<FDataBlock> BlockRef = MakeShareable(Raw);
    // 从这里开始，Raw 不再归你管理，最好置空
    Raw = nullptr;

    // TSharedRef 可以直接转 TSharedPtr
    TSharedPtr<FDataBlock> BlockPtr = BlockRef;

    // TWeakPtr 不影响引用计数
    TWeakPtr<FDataBlock> BlockWeak = BlockPtr;

    // 从弱引用升级时，Pin() 返回一个临时 TSharedPtr
    if (TSharedPtr<FDataBlock> Locked = BlockWeak.Pin())
    {
        UE_LOG(LogTemp, Log, TEXT("Value: %d"), Locked->Value);
    }
}

这段代码演示了 TSharedRef -> TSharedPtr -> TWeakPtr -> TSharedPtr 的完整链路。Pin() 在这条语句期间会保证对象不被释放，所以即使其他地方正在析构，只要引用计数还有这个临时强引用，对象就安全。这也是弱指针观察模式的常见写法。

4.2 自定义删除器的接管场景

有一类对象不能用普通 delete 释放，比如从内存池分配、需要走 Release 接口、或者对象分配和释放来自于不同模块。这时不能直接用 MakeShareable，因为它默认走 delete Object。正确做法是用 TSharedPtr 的带删除器构造：

cpp复制FDataBlock* Raw = Pool->AllocBlock();

TSharedPtr<FDataBlock> BlockPtr(
    Raw,
    [Pool](FDataBlock* P)
    {
        Pool->FreeBlock(P);
    });

这个构造路径不经过 MakeShareable，而是直接使用 TSharedPtr 的代理构造，允许第二个参数注入释放逻辑。我建议把这类接管统一封装成工厂函数，比如 MakeShareableFromPool(...)，避免散落在调用方代码中，后续审计也方便。

4.3 MakeShareable 和 MakeShared 的选型对比

很多新手会问：既然 MakeShared 性能更好，为什么还要用 MakeShareable？答案在于输入不同。我把两者对比整理成表：

我的习惯是：能在内部新建对象就用 MakeShared；但如果对象是从外部系统传进来的裸指针——尤其来自反射回调、插件接口、C 风格 SDK——就一定用 MakeShareable 接管，把它纳入共享所有权体系，绝不在模块边界上裸传。两种方式解决的问题不同，不存在谁完全替代谁。

4.4 析构顺序和返回值设计的官方推荐写法

当函数需要返回共享对象时，返回值类型我建议用 TSharedRef 而不是 TSharedPtr，因为非空契约能让调用方少写一个判空分支：

cpp复制TSharedRef<FDataBlock> LoadDataBlock(int32 Key)
{
    FDataBlock* Raw = DataCache->Lookup(Key);
    if (!Raw)
    {
        Raw = DataCache->CreateNew(Key);
    }
    return MakeShareable(Raw);
}

核心逻辑就是：先从缓存查，查不到就新建，最终返回一个非空引用。调用方拿到就必须处理，类型层面已经保证有效性。如果某条路径确实可能加载失败，就把返回值改成 TSharedPtr 并允许返回空。

5. 常用排查方式：共享指针常见的四个坑与对应方案

5.1 二次释放崩溃：控制块重复创建

症状是程序在 delete 处崩溃，或者报出堆损坏。我先假设最大嫌疑：调用了 MakeShareable(RawPtr) 之后，又用其他方式对同一个裸指针创建了第二个控制块。

cpp复制// 错误示例
FDataBlock* Raw = new FDataBlock();
TSharedRef<FDataBlock> Ref1 = MakeShareable(Raw);
TSharedRef<FDataBlock> Ref2 = MakeShareable(Raw); // 第二个控制块，对象被接管两次

两个控制块都不知道对方的存在。第一个引用计数归零时 delete 一次，第二个归零时又 delete 一次。排查时我会先全局搜一下这个裸指针出现的所有位置，看看是不是有多个构造入口。如果确认是外部传入的指针，建议把创建收敛到一个统一入口函数。

5.2 循环引用导致内存泄漏：引用计数永远到不了 0

症状是对象析构函数不执行，内存只涨不跌。典型父子结构：

cpp复制class FParentNode : public TSharedFromThis<FParentNode>
{
public:
    TSharedPtr<FChildNode> Child;
};

class FChildNode
{
public:
    TSharedPtr<FParentNode> Parent;
};

父持子、子持父，两个引用计数都始终至少为 1。要打破这条链，只需要把其中一个方向改成 TWeakPtr，通常是“子 -> 父”方向，因为父节点通常是生命周期更长的持有者：

cpp复制class FChildNode
{
public:
    TWeakPtr<FParentNode> Parent;
};

弱引用不增加引用计数，父节点析构后，子节点的 Parent.Pin() 返回空，代码逻辑上也能感知父节点消失。

5.3 线程安全模式带来的原子操作开销

默认 ThreadSafe 模式对引用计数的增减使用原子操作，在高频创建销毁共享指针的单一线程场景里，性能损耗是可测量的。如果确认对象不会跨线程，可以用 NotThreadSafe：

cpp复制TSharedPtr<FDataBlock, ESPMode::NotThreadSafe> LocalPtr;

但这是个双刃剑：一旦用了 NotThreadSafe，任何跨线程传递都变成未定义行为，调试成本剧增。我通常只在性能热点且完全单线程的内部工具模块里用，全局业务对象一律保留默认安全模式。

5.4 错误地给 UObject 包一层 TSharedPtr

还有一个常见误区：用 MakeShareable 接管 UObject*。UE 的 UObject 生命周期由垃圾回收和资产加载系统管理，不归引用计数管。即便你包了一层 TSharedPtr，GC 可能随时回收这个对象，引用计数却毫不知情，最终 Pin() 出来的是悬挂指针。

官方注释明确用一句话区分：智能指针服务于纯 C++ 对象，UObject 应该用 TWeakObjectPtr、UPROPERTY 引用和 GC 机制来管理。遇到 UObject* 该思考的不是包不包 TSharedPtr，而是该用哪个 UObject 生命周期指针。

6. 注释大纲之外的实践心得：几个值得养成的好习惯

最后分享几点我实际踩坑后总结的操作习惯，算是注释的补充。

第一，所有挂在 TSharedPtr 上的裸指针必须在第一行置空。这个习惯能避免大量二次释放问题。哪怕只是一个函数的局部变量，置空成本是零，但能杜绝后续维护者误用。

第二，审代码时只要看到裸指针传入 TSharedPtr 或 TSharedRef 构造函数，我都会要求对方确认所有权转移流程，并优先收敛到 MakeShareable 统一入口，避免散落构造路径。

第三，遇到共享对象的生命周期问题，不要只盯着崩溃位置，先全局搜一下对象有哪些地方创建了引用。我调试过一个模块，问题根源就是某个底层系统缓存了 TSharedRef，导致对象一直被引用，业务逻辑以为释放了，实际还活着。查引用计数虽然不能直接通过公开 API 打印，但在调试器里查看控制块的计数还是可行的。

第四，MakeShareable 更适合在模块边界做“所有权适配”，不要把它当成常规对象创建的替代品。如果每个类内部新建对象都优先 MakeShared，长期维护时分支会少很多。

这套思路在我实际项目中解决了不少棘手问题。你如果有类似经历，比如在异步回调或者插件接口里因为裸指针吃过亏，换成共享所有权体系之后多半也能立竿见影。下一步想深入的话，可以顺着 TReferenceControllerBase 的引用计数实现继续读源码，那里是理解 UE 智能指针性能特征的最后一环。