C++类型擦除详解：从std::function到std::any的底层原理与工程实践

在vscode里写C++写到一定阶段，总会撞上一个很微妙的问题：你写了一个模板函数，它能接收任意类型的可调用对象，但你想把它们统一存进一个std::vector，却被编译器无情地拒绝了——因为模板函数每实例化一次就是一个新类型，它们之间没有任何公共基类。这时候你就碰到了C++里最值钱也最容易绕晕的概念之一：类型擦除（type erasure）。

今天这篇东西，我打算把type erasure从“听上去很玄”讲到“源码级别能看懂”，再把工程里最常见的使用场景、性能代价、以及我踩过的一些坑全部铺开。适合正在学C++的初学者看得懂大概，也适合写了两三年C++但一直没搞透std::function和std::any底层原理的人静下心读一遍。

1. 类型擦除到底解决了什么问题——从一次“存不住”的编译错误说起

1.1 模板和虚函数：两种多态各自的天生缺陷

C++里有多态，而且不止一种。模板是编译期多态，编译器根据调用时的具体类型生成对应代码。虚函数是运行期多态，通过隐藏的vptr（虚表指针）在运行时找到真正的函数入口。

先说模板。模板写起来非常爽，std::sort可以对任何迭代器排序，std::thread可以接收任何可调用对象。但模板有个致命问题：它没法把一个类型不确定的东西存起来。

cpp复制template <typename F>
void run_with_log(F f) {
    std::cout << "start\n";
    f();
}

// 假设有两个不同的 lambda
auto a = []() { std::cout << "A\n"; };
auto b = []() { std::cout << "B\n"; };

// 不行！a和b是两种完全不同的类型，vector需要元素类型一致
// std::vector<???> functions = {a, b};

a的类型可能是main::$_0，b的类型是main::$_1，编译器根本不会帮你找到它们的“公共祖类”，因为lambda之间没有任何继承关系。

虚函数是运行期多态，它把“类型不同但行为相似”的类统一到一个基类接口下。但它要求所有参与多态的类必须显式继承同一个基类，而且基类里得有虚函数。这逼着使用者去修改自己的类，对于第三方库、内置类型、lambda表达式，这个方案直接不成立。

那能不能既不用继承、又能在运行时统一处理不同类型呢？这就是type erasure的出发点。

1.2 类型擦除最直白的理解：对外一个壳，对内一张表

我自己的理解方式很简单：类型擦除就是把“具体类型”藏起来，只暴露“接口签名”。

想象你去饭店点餐，菜单上写的是“清蒸鲈鱼”，你不需要知道后厨用的是哪条鱼、哪个师傅、哪口锅，你只需要知道点这个菜最后会上来一份清蒸鲈鱼。这里“清蒸鲈鱼”就是被擦除之后的统一接口，具体是海鲈鱼还是淡水鲈鱼、师傅姓张还是姓李，都是被藏在背后的具体类型。

在C++代码里，类型擦除最经典的三件套是std::function、std::any和std::variant——当然严格说std::variant不算擦除，它保留了类型集合。std::function擦除掉“可调用对象的具体类型”，只保留operator()的签名；std::any擦除掉一切类型，只保留“能存、能取”这个核心能力。

1.3 为什么lambda调用要经过“二次跳转”才能到真正的函数

很多人在刚接触std::function时有个疑惑：我直接把lambda赋给auto，调用的时候不是直接内联吗？为什么要包一层function反而更慢？

因为你一旦把一个lambda放进std::function，lambda的具体类型就被藏起来了。调用时编译器看到的是一个统一的函数签名void()，它只能通过std::function内部的函数指针或虚函数跳到真正的lambda实现上。这就是多了一次间接调用的来源。后面第3节我会详细展开代价。

2. 从零实现一个迷你std::function——继承和函数指针两条路都走一遍

2.1 用抽象基类做类型擦除：最快能跑起来的思路

先看教科书里最常见的一种实现方式：用一个抽象基类定义统一接口，然后用模板派生类承接具体类型，最后通过基类指针调用。

cpp复制class CallableBase {
public:
    virtual ~CallableBase() = default;
    virtual void call() const = 0;
};

template <typename F>
class CallableHolder final : public CallableBase {
public:
    explicit CallableHolder(F f) : f_(std::move(f)) {}
    void call() const override { f_(); }
private:
    F f_;
};

class Function {
public:
    Function() = default;

    template <typename F>
    Function(F f) : base_(std::make_unique<CallableHolder<F>>(std::move(f))) {}

    void operator()() const { base_->call(); }

private:
    std::unique_ptr<CallableBase> base_;
};

思路非常清晰：CallableHolder<F>把任何可调用对象F装进一个统一的CallableBase接口下，外部只知道CallableBase有这个call()，具体的F被藏在了里面。这就是一种完完全全的type erasure：对外暴露的是void()签名，对内具体类型是什么，外部完全不知道。

用起来也很顺手：

cpp复制Function f1 = []() { std::cout << "hello\n"; };
Function f2 = []() { std::cout << "world\n"; };
std::vector<Function> funcs;
funcs.push_back(f1);
funcs.push_back(f2);
for (const auto& f : funcs) f();

但是这个实现有三个明显短板：

• 每一次构造都有一次std::make_unique，产生堆分配。分配小对象，对于一个高频调用、高频拷贝的场景是不可接受的。
• 这类实现不支持拷贝。std::unique_ptr<CallableBase>不让拷贝，如果你想把Function f3 = f1;就会编译失败。标准库的std::function是可拷贝的，意味着内部的CallableBase必须支持clone。
• 存在虚函数调用，会多一次vtable跳转。

2.2 用函数指针表做类型擦除：把虚函数表手动搬到数据成员里

既然虚函数就是“隐藏的函数指针集合”，那我们可以手工把这份表存成普通数据成员，省掉vtable，甚至可以把“调用、销毁、拷贝”三个操作都压进同一张表里。

cpp复制template <typename Ret, typename... Args>
class Function<Ret(Args...)> {
public:
    Function() = default;

    template <typename Callable>
    Function(Callable c) {
        callable_ = new Callable(std::move(c));
        invoke_ = [](void* p, Args... args) -> Ret {
            return (*static_cast<Callable*>(p))(std::forward<Args>(args)...);
        };
        destroy_ = [](void* p) { delete static_cast<Callable*>(p); };
    }

    Function(const Function& rhs) : callable_(rhs.clone_(rhs.callable_)),
                                    invoke_(rhs.invoke_),
                                    destroy_(rhs.destroy_),
                                    clone_(rhs.clone_) {}

    ~Function() { if (callable_) destroy_(callable_); }

    Ret operator()(Args... args) const {
        return invoke_(callable_, std::forward<Args>(args)...);
    }

private:
    void* callable_ = nullptr;
    Ret (*invoke_)(void*, Args...) = nullptr;
    void (*destroy_)(void*) = nullptr;
    void* (*clone_)(const void*) = nullptr;
};

注意这里的两个关键点：

• 模板构造函数是Function这类的中枢。外部传入什么类型的可调用对象，它就用static_cast<Callable*>把void*还原回真身，然后丢进一个静态函数指针里。因为函数指针模板参数每次实例化都不一样，所以同一个Function<void()>可以装下无数种不同类型的lambda。
• 我把拷贝也做了进去，新增了一个clone_函数指针。这样拷贝Function的时候，它就知道怎么复制里头的对象。这就是标准的“函数指针表”式type erasure。

这版实现已经非常接近libstdc++和libc++中早期std::function的实现思路了。不过它还缺一个东西：小对象优化（SBO），也就是栈上缓冲区。

3. Small Buffer Optimization：怎么让type erasure“少一次堆分配”

3.1 一个24字节的栈上缓冲区能装下多少东西

堆分配很贵。malloc一次小对象，可能要走到系统调用、要维护分配链表、要处理内存碎片。尤其是std::function这种会被到处传、到处拷贝的东西，每构造一次就malloc一次，性能上完全扛不住。

经典实现里通常会在Function对象内部留一块栈上缓冲区，把“足够小的可调用对象”直接放进这块缓冲区里，而不是放到堆上。

比如libstdc++的实现里，_M_invoker内部会有一个固定大小的缓冲区。我自己的一个简化版长这样：

cpp复制class Function {
public:
    static constexpr size_t buffer_size = 24;

    Function() = default;

    template <typename F>
    Function(F f) {
        using DecayedF = std::decay_t<F>;
        if constexpr (sizeof(DecayedF) <= buffer_size 
                      && alignof(DecayedF) <= alignof(std::max_align_t)
                      && std::is_nothrow_move_constructible_v<DecayedF>) {
            // 栈上构造，用放置new
            new (&buffer_) DecayedF(std::move(f));
            is_inline_ = true;
        } else {
            callable_ = new DecayedF(std::move(f));
            is_inline_ = false;
        }
        setup_vtable<DecayedF>();
    }

private:
    alignas(std::max_align_t) unsigned char buffer_[buffer_size];
    void* callable_ = nullptr;
    bool is_inline_ = false;
};

注意这里有个非常关键的判断条件：不仅sizeof要小于等于24，alignof也要满足对齐要求。如果对象的大小和对齐都OK，就直接在buffer_里用placement new构造；否则回到堆分配。

为什么对齐很重要？因为如果某个类型的对齐要求是16字节，而内部缓冲区只按8字节对齐，storing it进去会直接触发未定义行为（UB）。在x86上可能还能忍，在ARM上直接段错误。所以缓冲区必须用alignas(std::max_align_t)声明，保证至少满足系统中最大标量类型的对齐。

3.2 placement new和显式析构：栈上对象的生命周期管理

SBO让事情变得微妙了：既然对象是直接放在buffer_这个原始字节数组里的，它就没有“自动构造/析构”的能力。我们必须手动管理它的生命周期。

• 构造：用new (&buffer_) DecayedF(std::move(f))，把对象在预分配的内存地址上构造出来。
• 析构：在~Function()里，先判断是不是inline存储。如果是，就用static_cast<DecayedF*>(static_cast<void*>(&buffer_))->~DecayedF()显式析构。
• 拷贝：如果是inline存储，就得用placement new在新的buffer_里复制一份。

这里有个隐蔽的坑：当你把void*转换回具体类型指针时，不能直接reinterpret_cast<DecayedF*>(&buffer_)就完事，必须要先转成void*再转回来。因为&buffer_的类型是unsigned char(*)[N]，直接强转成DecayedF*在标准上是不允许直接做reinterpret的（除非用void*中转一下）。这是标准规定的细节，但实际编译器通常都能处理，只是严谨起见要把这个中转转换写出来。

3.3 什么时候SBO会失败——那些塞不进去的大对象

SBO并不总是成功。比如你写了一个lambda，捕获了一个std::array<int, 100>，这个lambda的大小轻松超过24字节，SBO就只能放弃，落到堆分配。再比如有些可调用对象内部有std::string，而std::string本身在栈上也有SSO（小字符串优化），但你把它整个作为捕获物塞进lambda时，lambda的大小也可能超过缓冲区上限。

实测下来，常见的lambda大小大概在8到48字节之间。捕获一个int是8字节，捕获一个std::string常常是40字节以上，这时候SBO大概率直接失效。所以做性能敏感代码的时候，如果必须用std::function，尽量让lambda捕获的变量小一点，捕获指针而不是捕获整个结构体，能把SBO命中率从“偶发”提升到“稳定”。

我自己的经验是：如果性能要求高到不能容忍堆分配，那就不要用std::function，直接用带模板参数的std::span<F>、template<typename F> void visit(F&& f)这类编译期多态方案。type erasure的意义是“解耦”，不是“零成本”。零成本选项在类型确定时就该直接下手。

4. std::any和std::function的源码级理解——标准库到底替你干了多少活

4.1 std::any:一个真正“存储任何类型”的类型擦除容器

std::any是C++17进标准库的。它比std::function更激进：不管是什么类型，只要可拷贝、可析构，都能扔进std::any里，存下来。它擦除了一切类型信息，只保留两个核心能力：存储、按类型取回。

它的简化实现和上面Function的继承版本几乎一模一样。一个抽象基类定义“克隆、销毁”接口，一个模板派生类Holder<T>持有真正的值。

cpp复制class any {
public:
    any() = default;

    template <typename T>
    any(T&& value) {
        using DecayedT = std::decay_t<T>;
        content_ = new Holder<DecayedT>(std::forward<T>(value));
    }

    template <typename T>
    friend T any_cast(const any& a) {
        // 略过类型检查
        auto holder = dynamic_cast<const Holder<std::decay_t<T>>*>(a.content_);
        return holder->value;
    }

private:
    struct Base {
        virtual ~Base() = default;
        virtual Base* clone() const = 0;
    };

    template <typename T>
    struct Holder : Base {
        T value;
        explicit Holder(T v) : value(std::move(v)) {}
        Base* clone() const override { return new Holder(value); }
    };

    Base* content_ = nullptr;
};

真实的标准库实现还会带SBO，因为很多值其实很小。你在调试器里看libc++的实现，能看到_Storage里有一块内嵌缓冲。它能省掉一大部分堆分配。

std::any最大的注意点是：存进去和取出来必须用完全一致的类型，否则会抛std::bad_any_cast。就是说，你存了一个int，然后打算用long取回来？不行，会抛异常。很多人第一次用any_cast<long>(a)取了半天找不到为什么，回头看发现当初存的时候是int。

4.2 std::function：带签名约束的类型擦除

std::function和std::any的区别在于，它有一个签名约束。std::function<void(int)>只关心“能拿int调用、返回void”的可调用对象，而不关心那个对象到底是什么。它在type erasure的基础上，叠加了一层参数的静态校验——这层校验发生在编译期，所以它是“带签名的类型擦除”。

标准库对std::function的空对象也有定义：默认构造的std::function是空的，调用它会抛std::bad_function_call。这个特性和std::any抛bad_any_cast是同一个设计思路：如果内部没有东西，就别假装能调用成功。

std::function还保证了可拷贝性。也就是说，它内部存放的可调用对象也必须是可拷贝的。如果你把只可移动的lambda塞进去，编译就报错。这个限制让很多人头疼，因为C++11之后的很多资源型对象都是move-only的。直到C++23才加入std::move_only_function来解决这个问题，它允许存储不可拷贝、只可移动的可调用对象，代价是自身也变成move-only。

4.3 std::variant和std::any的区别：被擦除和没被擦除的差异

很多人会把std::variant和std::any放在一起比较。这里有一个非常本质的区别：

• std::variant<int, double, std::string> 是一个sum type，它的可能类型集合是编译期确定的。你构造它的时候，编译器知道你在几个候选类型中选了一个，并且能对每个可能类型进行静态检查。它的开销几乎为零，就是可能类型中最大那个的size然后加一个tag。
• std::any 不限类型集合，你想放什么就放什么，运行期才知道具体是什么。它的动态分配、虚函数跳转、类型检查全是运行期成本。

所以我自己的选型原则是：如果可能用到的类型是已知的一个有限集合，用std::variant；如果类型集合完全开放、就是想要极致灵活，才用std::any。std::any不是代替std::variant的，两者是不同层面的设计工具。

5. 真实工程里的类型擦除：事件总线、异质容器和插件系统的边界

5.1 线程池任务队列：为什么所有任务都必须是std::function<void()>

在你写的第一个多线程C++程序里，一定会遇到这种场景：线程池里要接收各种各样不同的任务函数，有的无参无返回值，有的接收参数、返回结果。经典做法就是把它们全部统一成std::function<void()>，然后塞进同一个任务队列。

cpp复制class ThreadPool {
public:
    void enqueue(std::function<void()> task) {
        {
            std::lock_guard<std::mutex> lock(mutex_);
            tasks_.push(std::move(task));
        }
        cv_.notify_one();
    }

private:
    std::queue<std::function<void()>> tasks_;
    std::mutex mutex_;
    std::condition_variable cv_;
};

为什么这里非得用type erasure？因为std::queue要求元素类型一致。如果你用模板：

cpp复制template <typename F>
void enqueue(F task);

那每传入一种新的任务类型，enqueue就被实例化成一个新函数，这没问题。但问题在于任务队列本身，它需要的是“把类型不确定的任务存储起来”。这时类型擦除就是唯一选择。

再往深层看：线程池里还要把std::packaged_task包装成throw异常的任务。std::packaged_task是move-only类型，不能被std::function存储——所以实际工程里通常再套一层lambda捕获std::packaged_task，包成std::function<void()>。或者直接用std::move_only_function（C++23）。

5.2 异质容器：vector和vector<unique_ptr>到底怎么选

有人问我，既然有std::unique_ptr<Base>，为什么还需要std::any？什么情况下真的需要一个std::vector<std::any>？

我的判断是两个维度：

• 如果类型集合开放，且你对其中元素的操作非常有限——只是存进去、取出来、没有共同行为接口——用std::any。
• 如果这些对象之间有明显的行为共性，比如都要画图、都要序列化、都要输出，那么定义一个抽象基类然后放std::unique_ptr<Base>是更清晰、也更能表达设计意图的方案。

std::vector<any>的真实用途其实比较小众。我见过比较合理的用法是在配置系统里，解析配置文件时key对应的value类型飘忽不定，可能是int、double、string、bool，用一个map<string, any>来暂存解析结果，之后按需转成具体类型。这种场景下，any作为“无类型的数据容器”非常合适。

5.3 插件接口：把虚函数藏起来，只暴露一个函数指针

插件系统的header往往长这样：

cpp复制extern "C" PluginAPI* create_plugin();

PluginAPI是一个纯虚接口，插件自己实现，主程序通过虚函数调用。这是一种古典的type erasure实现——通过一组固定虚函数接口把具体插件实现藏起来。主程序不需要知道插件内部是怎么写的，只要它继承PluginAPI并实现那几个纯虚函数就行。

但如果你更进一步，用函数指针做成C接口，那其实就是回到第2节讲的东西：void*加函数指针表。对于真正的插件体系（比如需要跨DLL边界传递），纯虚函数接口更安全，因为编译器和链接器会帮你处理很多vtables的细节；手搓函数指针表反而容易踩到ABI兼容性的坑。

所以type erasure在跨边界场景下不是“越底层越好”，标准库抽象往往是更省心的选择。

6. 性能与踩坑：为什么有人说类型擦除慢，以及怎么避坑

6.1 一次间接调用而已——不要神化也不要妖魔化

在x86-64上，一次虚函数调用大约是一两次内存读取加一次间接跳转，量级在1到3纳秒。SBO命中的std::function也类似，如果lambda内部逻辑不复杂，这两者可能只比直接调用慢一两倍；如果lambda内部本身就有重活，那这个相对差异基本可以忽略。

真正慢的不是调用本身，而是构造和拷贝时的堆分配。所以我做性能profile时，第一步永远是检查std::function的构造点。如果发现某个高频率路径上在不停创建新的std::function——比如每个事件都要包一层lambda再塞进队列——那就得考虑复用std::function、把构建成本移出热点循环，或者改回模板。

我这个表格整理了一下三种实现的典型成本：

6.2 SBO失效时的隐式堆分配：你的function可能在偷偷malloc

这是类型擦除最阴险的性能陷阱。代码看着没分配内存，实际上std::function内部有个24字节的栈缓冲区，装得下就栈上，装不下就malloc。你完全感知不到这个分配，因为它是隐式发生的。

怎么排查？在Linux下可以用LD_PRELOAD一个自定义malloc来统计，或者在代码里手动放大缓冲区（不同平台实现不同，不建议这么做）。更实用的办法是：大lambda拆分，把捕获量大的部分改成指针。

cpp复制// 坏的写法：一个巨大对象被lambda捕获，sizeof(lambda)非常大
auto huge = std::array<int, 64>();
std::function<void()> f = [huge]() { process(huge); };

// 好一点的写法：只捕获指针，lambda大小降到8字节
auto huge = std::make_shared<std::array<int, 64>>();
std::function<void()> f = [huge]() { process(*huge); };

第二个版本虽然多了一次shared_ptr引用计数操作，但它不会触发SBO失效导致的堆分配。在热点路径上，通常是赚的。

6.3 一个非常隐蔽的坑：类型擦除类型在调试器里难以辨认

std::function内部存放的lambda类型，在调试器里基本是看不见的。你在Visual Studio里看一个std::function，它显示一个大黑盒：std::function<void(void)>。你想知道里面到底是哪个lambda，根本看不出来。GDB稍微好点，能看到内部存储的函数指针地址，但要把那个地址解析回lambda的具体类型，仍然很费劲。

这时候最有效的办法是打印函数指针地址，在代码里临时加一行std::cout << f.target_type().name() << std::endl;。std::function提供了target_type()接口，能拿到被擦除类型的type_info，从而得知实际类型名。调试大型事件系统时，这个接口能快速定位到底是哪个handler被注册了。

6.4 什么时候绝对不要用类型擦除

类型擦除不是银弹。我见过有人用std::function写算法库的每一层，外层套std::function，内层还套std::function，结果就是一堆间接调用堆叠，性能直线下降。我的个人判断标准非常明确：

• 类型在编译期确定，且没有存储需求时，绝不使用type erasure。直接用模板。
• 类型集合有限，且有明确的行为接口时，优先定义抽象基类，有虚函数就有虚函数，别为了“显得现代”硬上std::function。
• 只有类型集合开放、或者需求本身就是存储任意可调用对象/任意值时，才考虑type erasure。

写模板时的“通用性”是编译期的，写在代码里一眼能看穿。类型擦除的“通用性”是运行期的，好处是灵活，代价是运行时多态的所有成本。能编译期解决的，就不要拖到运行期。

最后分享一个我实际工作中的习惯：在写回调类接口时，我会默认用std::function作为参数类型，但内部保存时尽量用move，外部传入时尽量传rvalue，这样能享受到SBO的好处又不会产生多余的拷贝。如果做底层框架，还会把std::function<void()>的构建点集中到少数几个地方，方便后续profile和优化。类型擦除本身不复杂，复杂的是什么时候该擦、什么时候不该擦——这个判断力，是靠着写、靠着跑、靠着在调试器里看那些黑色类型名一个个踩出来的。