Day 33：类型擦除（Type Erasure）

类型擦除（Type Erasure）是一种把「具体类型」从对外接口上抹掉、只保留「行为契约」，同时让外壳类型拥有值语义（可拷贝、可赋值、可放进容器、可作为返回值）的设计技术。它是 C++ 里外部多态（external polymorphism）的标准实现方式，也是 std::function、std::any、QVariant、QMetaObject::invokeMethod 背后的共同机制。

昨天（Day 32 依赖注入）我们解决了「依赖从哪里来」，今天解决的是「怎么把五花八门的实现装进同一个统一的、可拷贝的、可反射的容器里」。这两件事合起来，就是一套可插拔架构的地基。

假设你要写一个渲染器，需要在一份「场景」里遍历绘制所有图元。你手上有 Circle、Rect、Text 三种互不相干的类型。方案无非两条老路，都有硬伤。

坏代码 A：模板泛型 —— 异构容器装不下，头文件泄漏实现

// ❌ 反例 A：模板把「具体类型」钉死在调用点上
#include <vector>
#include <string>

struct Circle { void render() const; };
struct Rect   { void render() const; };

template <class T>
void renderAll(const std::vector<T>& items) {   // 每个 T 生成一份独立代码
    for (const auto& it : items) it.render();
}

void demo() {
    std::vector<Circle> circles;
    std::vector<Rect>   rects;
    renderAll(circles);      // 编译期就固定了 T
    renderAll(rects);        // 又实例化一份
    // std::vector<???> scene;  // ← 想把 Circle 和 Rect 放进同一个容器？办不到
}

问题清单：① 异构容器无解——你无法声明一个既能装 Circle 又能装 Rect 的 std::vector；② 头文件泄漏——renderAll 必须被使用者可见（模板定义要在头文件里），库的内部实现被拖进每个编译单元；③ 代码膨胀与编译变慢——N 个类型 × M 个泛型函数就是 N×M 份实例化代码；④ ABI 不稳定——模板实例无法安全地跨 DLL/so 边界传递，插件化架构直接崩掉。

坏代码 B：侵入式基类 —— 逼所有人继承你

// ❌ 反例 B：为了统一，强制所有类型继承你自己的基类
class IDrawable {
public:
    virtual ~IDrawable() = default;
    virtual void render() const = 0;
};

class Circle : public IDrawable {           // 我自己的类：能改，勉强忍
public:
    void render() const override;
};

// 现在你想渲染一张第三方库的图片，或者一段 std::string：
//   class QImage / class std::string  —— 你能让它们继承 IDrawable 吗？不能。
// 于是只能写壳子类，壳子又要管生命周期，越写越脏：
class ImageAdapter : public IDrawable {
public:
    explicit ImageAdapter(QImage img) : m_img(std::move(img)) {}
    void render() const override { /* 转发 */ }
private:
    QImage m_img;
};

问题清单：① 侵入性——被包装类型必须改造自身（继承、加基类成员、多一个 vptr），第三方类型根本改不了；② 能力维度爆炸——同一个类如果既要「可渲染」又要「可序列化」还要「可克隆」，就得挂上三张基类，接口继承树迅速变成蛛网；③ 测试替身被迫继承——写个 Mock 也得继承你的生产基类，测试与实现强绑定。

通俗解释。你写 virtual void render() 时，编译器偷偷做了一件事：给这个类生成一张函数指针表（vtable），每个对象里塞一个指针（vptr）指向它。多态性「长在实现者身上」。

类型擦除做的事，是把这张表手工写到外壳身上：外壳内部持有一个 Concept*（纯虚接口，等价于那张表），而 Model<T> 是编译器为每个 T 自动生成的「适配器」，把 T::render() 接到 Concept::render() 上。于是——

• 对调用方而言，他只知道外壳（AnyDrawable / std::function / QVariant），看不到 T；
• 对实现者（Circle、一个 lambda、你自己的类）而言，它不知道自己被包装了；
• 唯一的知情者是那个模板构造函数，它同时看得见两者，负责「接线」。

生活类比一：出租车公司。乘客只认「这是一辆能载客的车」这个契约，不关心是油车、电车还是混动。签约那一刻（构造外壳那一刻），公司把「怎么启动、怎么计价、怎么开门」登记成一张任务表（vtable）挂在车（外壳）上。乘客对着「车」发号施令，具体动作由登记表决定。

生活类比二：USB 接口。USB 口 = 外壳（固定尺寸、固定插法）；U 盘/键鼠/网卡 = 具体类型（彼此毫无关系）；USB 协议 = Concept（只规定供电、枚举、传输这几件事）；插头里的控制芯片 = Model<T>（唯一知道「我是键盘，我的报文长这样」的角色）。

以下是 AnyDrawable 的结构关系（文字版类图；箭头含义按 UML 约定：实线空心三角 = 继承，菱形 = 组合/拥有，虚线箭头 = 依赖）：

        ┌──────────────────────────────────────────┐
        │            AnyDrawable  (Wrapper)         │   ← 用户只看到这个类型
        │  - unique_ptr<DrawableConcept> m_self     │      · 值语义（可拷贝/可移动）
        │  + AnyDrawable(T&&)        模板构造函数   │      · 恒定大小（64 位下 8 字节）
        │  + render() const                        │      · 非虚函数，直接调用
        └───────────────────┬──────────────────────┘
                            │ ◆ 组合（拥有，生命周期绑定）
                            ▼
        ┌──────────────────────────────────────────┐
        │        DrawableConcept  «interface»       │   ← 唯一的多态出口
        │  + render() const = 0                    │      只暴露 2 个能力，多的一个不给
        │  + clone() const -> unique_ptr<Concept>  │      （供深拷贝用）
        └───────────────────▲──────────────────────┘
                            │ △ 继承（唯一用到继承的地方）
              ┌─────────────┴─────────────┐
              │                           │
   ┌───────────────────────┐   ┌───────────────────────┐
   │  Model<Circle>        │   │  Model<Text>          │   ← 由编译器按需生成
   │  - Circle m_value     │   │  - Text   m_value     │      · 按值持有（零侵入）
   │  + render()→Circle::  │   │  + render()→Text::    │      · 唯一知道 T 的类
   └───────────┬───────────┘   └───────────┬───────────┘
               │ 依赖（用 T 的成员函数）        │
               ▼                           ▼
        ┌─────────────┐             ┌─────────────┐
        │  Circle     │             │  Text       │   ← 它们完全不知道 Wrapper 的存在
        │  render()   │             │  render()   │      不继承、不加成员、不改一行
        └─────────────┘             └─────────────┘

角色	职责	它的「不知道」
Wrapper（AnyDrawable / std::function / QVariant）	对外提供稳定接口与值语义；拷贝时调用 clone()；析构时经 Concept 释放 T	不知道具体 T 是什么、有多大、怎么算
Concept（DrawableConcept）	定义「外壳必须提供的能力集合」——这是全系统唯一需要谨慎设计的部分（能力越少越好）	不知道有哪些实现，也不持有数据
Model<T>	把 T 的成员函数适配成 Concept 虚函数；负责 T 的构造/拷贝/析构；由编译器按 T 实例化	不知道调用方是谁，也不需要
被包装类型 T（Circle/Text/lambda）	只提供自己的成员函数（鸭子类型）	完全不知道 Wrapper、Concept 的存在（零侵入）
Storage（堆 / SBO 内联缓冲）	决定 T 放在哪：new 到堆，或放进外壳内的 aligned_storage	不知道 T 的语义，只关心大小与对齐

关键点：外壳与 Concept 之间是 组合（拥有），Concept 与 Model 之间是继承（全模式里唯一的一处继承），Model 与被包装类型之间也是组合（按值持有）。这就是「组合优于继承」的典型形态：继承只用来做一次「动作分发」，其余全是组合。

下面这份代码是完整可编译的单文件程序（本机 g++ 13.3 / C++17 已实测通过并运行）。它用 40 行核心代码把「内部多态」换成了「外部多态」。

// type_erasure_min.cpp —— 手写一个带值语义的类型擦除外壳（C++17）
// 编译：g++ -std=c++17 -Wall -Wextra type_erasure_min.cpp -o type_erasure_min
#include <functional>
#include <iostream>
#include <memory>
#include <string>
#include <type_traits>
#include <utility>
#include <vector>

// ---------- 1) 概念层：外壳要暴露的全部能力，只写在这里 ----------
struct DrawableConcept {
    virtual ~DrawableConcept() = default;
    virtual void render() const = 0;                              // 行为契约
    virtual std::unique_ptr<DrawableConcept> clone() const = 0;    // 值语义的关键
};

// ---------- 2) 模型层：唯一“知道”T 存在的地方 ----------
template <class T>
class Model final : public DrawableConcept {
public:
    explicit Model(T value) : m_value(std::move(value)) {}
    void render() const override { m_value.render(); }             // 适配成虚函数
    std::unique_ptr<DrawableConcept> clone() const override {
        return std::make_unique<Model<T>>(m_value);                 // 要求 T 可拷贝
    }
private:
    T m_value;                                                     // 按值持有，零侵入
};

// ---------- 3) 外壳层：用户看到的类型，值语义 + 异构容器 ----------
class AnyDrawable {
public:
    template <class T,
              class = std::enable_if_t<!std::is_same_v<std::decay_t<T>, AnyDrawable>>>
    AnyDrawable(T&& value)                                         // 模板构造函数（类本身不是模板！）
        : m_self(std::make_unique<Model<std::decay_t<T>>>(std::forward<T>(value))) {}

    AnyDrawable(const AnyDrawable& other) : m_self(other.m_self->clone()) {}
    AnyDrawable(AnyDrawable&&) noexcept = default;
    AnyDrawable& operator=(AnyDrawable other) noexcept {           // copy-and-swap
        m_self.swap(other.m_self);
        return *this;
    }

    void render() const { m_self->render(); }                      // 非虚，走一次指针转发

private:
    std::unique_ptr<DrawableConcept> m_self;                       // 只有一个指针
};

// ---------- 4) 三个互不相干的类型：都没有继承任何基类 ----------
struct Circle { void render() const { std::cout << "  (o) Circle  r=2.0\n"; } };
struct Rect   { void render() const { std::cout << "  [ ] Rect    3x4\n"; } };
struct Text   { std::string body; void render() const { std::cout << "  (T) " << body << "\n"; } };

int main() {
    std::vector<AnyDrawable> scene;                                 // 异构容器：反例 A 做不到的事
    scene.emplace_back(Circle{});
    scene.emplace_back(Rect{});
    scene.emplace_back(Text{"Hello Type Erasure"});

    AnyDrawable copy = scene[2];                                    // 值语义：深拷贝成立
    scene.emplace_back(std::move(copy));

    std::cout << "scene.size() = " << scene.size() << "\n";
    for (const auto& item : scene) item.render();
    std::cout << "sizeof(AnyDrawable)          = " << sizeof(AnyDrawable) << " bytes\n";
    std::cout << "sizeof(std::function<void()>) = " << sizeof(std::function<void()>) << " bytes\n";
}

实测输出（本机 g++ 13.3.0 -std=c++17 -Wall -Wextra -O2，无警告）：

scene.size() = 4
  (o) Circle  r=2.0
  [ ] Rect    3x4
  (T) Hello Type Erasure
  (T) Hello Type Erasure
sizeof(AnyDrawable)          = 8 bytes
sizeof(std::function<void()>) = 32 bytes

真实项目里最实用的形式不是手写 Model<T>，而是用两个已有的类型擦除容器组合出业务能力：用 std::function 擦除「怎么执行」，用 QVariantMap 擦除「参数类型」。这样任何一个服务类（不必继承任何基类）都能把自己的成员方法注册成一条可被统一调度、可被禁用、可被反射列表的动作。

文件 1：actionbus.h

// actionbus.h —— 一个类型擦除的动作总线
#pragma once

#include <QHash>
#include <QObject>
#include <QString>
#include <QStringList>
#include <QVariantMap>
#include <functional>

// 一个“动作”= 两段被擦除了类型的可调用对象 + 纯元数据
// 它自己不是虚基类，任何有对应操作的实现都可以被装进来（零侵入）
struct Action {
    QString id;                                    // 稳定标识，如 "view.zoom"
    QString title;                                 // 展示名（菜单/快捷键面板用）
    std::function<bool()> enabled;                  // 守卫：可为空 = 永远可用
    std::function<void(const QVariantMap&)> run;    // 参数类型被 QVariantMap 擦除

    bool isEnabled() const { return !enabled || enabled(); }
    void operator()(const QVariantMap& args) const { if (isEnabled()) run(args); }
};

class ActionBus : public QObject {
    Q_OBJECT
public:
    using ActionMap = QHash<QString, Action>;

    explicit ActionBus(QObject* parent = nullptr) : QObject(parent) {}

    void       registerAction(const Action& action);
    bool       contains(const QString& id) const { return m_actions.contains(id); }
    QStringList ids() const;                                        // 供菜单/命令面板枚举
    int        count() const { return m_actions.size(); }

    bool trigger(const QString& id, const QVariantMap& args = {});

signals:
    void actionTriggered(const QString& id, const QVariantMap& args);
    void actionRejected(const QString& id, const QString& reason);

private:
    ActionMap m_actions;
};

文件 2：actionbus.cpp

// actionbus.cpp
#include "actionbus.h"

#include <QtGlobal>

void ActionBus::registerAction(const Action& action)
{
    Q_ASSERT(action.run);                       // run 是唯一的必填项
    m_actions.insert(action.id, action);        // Action 是值类型，直接拷贝进哈希表
}

QStringList ActionBus::ids() const
{
    QStringList keys = m_actions.keys();
    keys.sort();                                // 稳定顺序，便于 UI 与测试断言
    return keys;
}

bool ActionBus::trigger(const QString& id, const QVariantMap& args)
{
    const auto it = m_actions.constFind(id);
    if (it == m_actions.constEnd()) {
        emit actionRejected(id, QStringLiteral("未注册的动作"));
        return false;
    }
    if (!it->isEnabled()) {                     // 守卫在调用前统一生效
        emit actionRejected(id, QStringLiteral("动作当前不可用"));
        return false;
    }
    (*it)(args);                                // ① 调用 std::function（类型已擦除）
    emit actionTriggered(id, args);             // ② 通知外部（可接日志、撤销栈、遥测）
    return true;
}

文件 3：main.cpp —— 三个互不相干的「服务」，谁都没继承任何基类

// main.cpp
#include <QCoreApplication>
#include <QTextStream>
#include "actionbus.h"

// 服务 1：文档（自有类）
class Document {
public:
    void save(const QString& path) { m_path = path; ++m_saves; }
    int  saves() const { return m_saves; }
    QString path() const { return m_path; }
private:
    QString m_path;
    int     m_saves = 0;
};

// 服务 2：主题（聚合类型，甚至没有一个方法叫 save/switchTo 之外的东西）
struct ThemeService {
    QString name = QStringLiteral("dark");
    void switchTo(const QString& n) { name = n; }
};

static QTextStream out(stdout);

int main(int argc, char** argv)
{
    QCoreApplication app(argc, argv);
    ActionBus bus;

    QObject::connect(&bus, &ActionBus::actionRejected,
                     [](const QString& id, const QString& why) {
                         out << "rejected: " << id << " (" << why << ")\n";
                     });

    Document     doc;                 // 服务 3：一个裸的 int，代表缩放级别
    ThemeService theme;
    int          zoom = 100;

    // ---- 注册：lambda 各自捕获需要的东西，动作总线对它们一无所知 ----
    bus.registerAction({
        QStringLiteral("file.save"), QStringLiteral("保存文档"),
        nullptr,                                            // 无守卫 → 永远可用
        [&doc](const QVariantMap& args) {
            doc.save(args.value(QStringLiteral("path"), QStringLiteral("untitled.txt")).toString());
        }
    });

    bus.registerAction({
        QStringLiteral("view.theme"), QStringLiteral("切换主题"),
        nullptr,
        [&theme](const QVariantMap& args) {
            theme.switchTo(args.value(QStringLiteral("name"), QStringLiteral("light")).toString());
        }
    });

    bus.registerAction({
        QStringLiteral("view.zoom"), QStringLiteral("缩放"),
        [&zoom] { return zoom < 400; },                     // 守卫：到上限就禁用
        [&zoom](const QVariantMap& args) {
            zoom = qBound(25, zoom + args.value(QStringLiteral("delta"), 10).toInt(), 400);
        }
    });

    // ---- 调用：参数类型被 QVariantMap 擦除 ----
    bus.trigger(QStringLiteral("file.save"), {{QStringLiteral("path"), QStringLiteral("report.md")}});
    bus.trigger(QStringLiteral("view.theme"), {{QStringLiteral("name"), QStringLiteral("solarized")}});
    for (int i = 0; i < 3; ++i)
        bus.trigger(QStringLiteral("view.zoom"), {{QStringLiteral("delta"), 150}});  // 100→250→400→被拒
    bus.trigger(QStringLiteral("view.zoom"), {{QStringLiteral("delta"), 150}});      // 已到上限，仍被拒
    bus.trigger(QStringLiteral("unknown.action"));

    out << "doc.saves = " << doc.saves() << "\n"
        << "doc.path  = " << doc.path()  << "\n"
        << "theme     = " << theme.name  << "\n"
        << "zoom      = " << zoom        << "\n"
        << "actions   = " << bus.ids().join(QStringLiteral(", ")) << "\n";
    return 0;
}

文件 4：CMakeLists.txt

cmake_minimum_required(VERSION 3.19)
project(actionbus LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_AUTOMOC ON)                 # actionbus.h 里有 Q_OBJECT，需要 moc

find_package(Qt6 REQUIRED COMPONENTS Core)

qt_add_executable(actionbus
    actionbus.h
    actionbus.cpp
    main.cpp
)
target_link_libraries(actionbus PRIVATE Qt6::Core)

# 构建：cmake -B build && cmake --build build && ./build/actionbus

预期输出（推导）：

rejected: view.zoom (动作当前不可用)
rejected: view.zoom (动作当前不可用)
rejected: unknown.action (未注册的动作)
doc.saves = 1
doc.path  = report.md
theme     = solarized
zoom      = 400
actions   = file.save, view.theme, view.zoom

这个例子里有两层类型擦除叠在一起，值得仔细看：

• std::function<void(const QVariantMap&)> 擦除了行为的类型：Document::save 的一个闭包、ThemeService::switchTo 的一个闭包、一段操作裸 int 的闭包，进到同一个 QHash 里都变成同一个类型 Action。
• QVariantMap（底层 QVariant）擦除了数据的类型：path 是 QString、delta 是 int，到了调用点统一是 QVariant，取用时 toInt()/toString() 还原。
• 结果是：新增一个功能 = 注册一条动作，不改 ActionBus 一行代码（OCP 达成）；而如果用虚接口 class IAction { virtual void run() = 0; }，每加一个功能就要新增一个类（哪怕只是一行调用），这在「几十个菜单项 + 快捷键 + 命令面板 + 撤销栈都指向同一动作」的场景就是灾难。

A. 最小示例：AnyDrawable d = Circle{}; 到 d.render()

1. 类型推导与接线。编译器用 T = Circle 实例化模板构造函数 → 生成 Model<Circle> 类 + 它的 vtable（render 槽指向 Circle::render，clone 槽指向 Model<Circle>::clone）。这一步发生在编译期、每个 T 一次。
2. 堆上安置。std::make_unique<Model<Circle>>(Circle{}) 分配内存，把 Circle 移动进 m_value，再把 Model<Circle>* 隐式向上转型为 DrawableConcept* 存进 m_self。此刻外壳里只有一个指针，sizeof == 8。
3. 拷贝分派。AnyDrawable copy = scene[2]; 调用拷贝构造 → m_self->clone() 虚分派 → 落到 Model<Text>::clone() → make_unique<Model<Text>>(m_value) 分配一块新内存并拷贝 Text。拷贝 = 深拷贝 + 一次堆分配，两个对象此后互不影响（值语义成立）。
4. 调用与析构。循环里 item.render() 是非虚的直接调用（编译器可内联进 m_self->render() 这一行），再经 vtable 分派到 Circle::render —— 比裸虚调用多一次「指针跟随」，代价是一次间接跳转。作用域结束时 unique_ptr 调用 virtual ~DrawableConcept() → Model<Circle> 析构 → Circle 析构 → 释放内存，全程 RAII，无一处 delete。

B. Qt 示例：bus.trigger("view.zoom", {{"delta", 150}})

1. 查找。m_actions.constFind(id) —— 一次字符串哈希查找，命中则拿到 const Action&。
2. 守卫求值。isEnabled() 调用被擦除的 std::function<bool()>（这里是捕获 &zoom 的 lambda），返回 zoom < 400。返回 false 就直接 emit actionRejected 且不执行 run。
3. 参数还原与执行。Action::operator() 调用 run(args) → std::function 内部的调用器把 QVariantMap 透传给闭包 → args.value("delta").toInt() 把 QVariant 还原成 int → qBound 夹紧后写回 zoom。
4. 通知外部。emit actionTriggered(...) → Qt 的信号槽机制（内部同样是被擦除的槽对象，见 ⑫ 的 QSlotObjectBase）把事件分发给所有接收者：日志、撤销栈、遥测都可以在这里挂上去，而 ActionBus 完全不知道它们存在。

1）解耦点在哪里。调用方只依赖 Concept（稳定、能力最小），实现方只依赖自己的成员函数名（鸭子类型）。两者之间不共享基类、不共享头文件、不共享 ABI。第三方类型（std::string、QImage、别人的 SDK 类）可以被直接包装，这是继承方案永远做不到的事。

2）扩展点是「实现维度」而不是「能力维度」。新增一种实现（Hexagon）零改动：只要它有 render()，Model<Hexagon> 由编译器自动生成，Concept 一个字都不用改——这正是 OCP。反过来说，新增一种能力（比如「求面积」）就必须改 Concept，所有 Model<T> 都会重新实例化并强制实现该能力。这是类型擦除的真实边界，不是缺点而是必须知道的约束：类型擦除对「实现」开放、对「能力」封闭。

3）DIP 与「组合优于继承」。外壳依赖抽象 Concept（高层不依赖低层细节）；外壳组合 Concept、Model组合 T，继承只出现一次且只用于「把动作分发出去」。对比反例 B，被包装类型身上不背任何来自框架的基类，一个类可以同时被三种不同的擦除外壳包装（可渲染、可序列化、可撤销），互不干扰。

4）可测试性与工程性。写完的 AnyDrawable 可以被 return、可以放进 std::vector/QHash/QList、可以作为类的成员变量——因为它有值语义。测试时不必为 Mock 继承任何生产基类，只要它有同名成员函数即可「注入」；也没人需要 mock AnyDrawable 本身。

5）编译防火墙与 ABI 稳定。外壳的尺寸与布局固定（std::function 32 字节、QVariant 固定 sizeof），头文件不必包含实现类型的定义。库的公开 API 里只出现外壳类型时，内部换实现不需要重新编译使用者——这正是插件化、DLL 边界的刚需（也是 Qt 为什么造 QVariant、为什么把信号槽参数做元类型注册的原因）。

爆炸 A：if-else / 枚举分派地狱（RTTI 版）——「我不知道类型，就用运行期判断吧」：

// ❌ 每新增一种图元，所有分派点都要改；第三方类型更无解
enum class Kind { Circle, Rect, Text };

struct Shape {              // 上帝结构体：所有图元字段堆在一起
    Kind kind;
    double w, h, r;
    std::string text;
};

void render(const Shape& s) {
    switch (s.kind) {       // ← 这个 switch 会在 20 个文件里重复出现
    case Kind::Circle: /* 画圆 */ break;
    case Kind::Rect:   /* 画矩形 */ break;
    case Kind::Text:   /* 画文字 */ break;
    }
}

后果：① 加一种形状 → 改 enum + 改所有 switch（OCP 全面沦陷）；② Shape 成了「什么字段都得有」的胖结构体，包不住第三方类型（QImage 的字段你写不进这个 struct）；③ 用 dynamic_cast/typeid 代替 enum 也只是把 switch 换成 if 链，且强制类型必须继承基类，仍然零侵入失败。

爆炸 B：类膨胀 / 适配器洪水——用继承方案包装 N 个第三方类型，就需要 N 个手写适配器类，每个都要管生命周期、拷贝、异常；如果这些第三方类型还要被包装进「可序列化」体系，就是 2N 个适配器。代码量随「类型数 × 能力数」平方增长。

爆炸 C：接口洪水与跨边界崩溃——为每个能力造一个虚接口（IRenderable、ISerializable、ICloneable），实现类继承一堆基类；想在 DLL 边界传递时又发现虚接口需要两端一致的类布局与 vtable 约定，容易出现「跨模块 delete」问题（不同堆、不同 CRT）。此时通常被迫退回「用 void* + 手工函数指针表」——那其实就是手工劣化版的类型擦除，因为 void* 丢掉了类型安全与值语义。

该用的信号（满足任意一条就值得考虑）：

1. 需要异构容器。场景/命令队列/任务池/事件列表里要装不同实现，且必须保有值语义（可拷贝、可排序、可 erase）。
2. 要包装第三方类型。类型不可改（QImage、std::string、SDK 里的 Client），但你需要它满足你定义的契约。
3. 库/框架的公开 API 边界。不想让使用者的头文件里出现你的实现类型，也不想让模板实例跨 DLL；接口需要 ABI 稳定。
4. 回调存储（最日常的用法）。「存一个待会儿要执行的函数」——std::function 是它的标准答案，把捕获了各种上下文的 lambda 统一成一个类型放进 QHash/QList。
5. 属性系统 / 反射 / 配置 / 序列化。类型在运行期才知道（JSON 配置、插件参数、属性面板、拖拽数据），这正是 QVariant + QMetaType 存在的理由。

不该用（会被虚接口或模板更划算）：

1. 实现类型编译期已知且单一。直接虚接口传引用（不拥有、零分配），或直接调具体类——别为了「将来可能扩展」先引入一层擦除。
2. 热路径里的百万次调用。每帧 10 万次 std::function 调用 + QVariant 解包是性能陷阱；这里应该用模板/概念/C++20 concepts 让编译器完全内联，或者把还原后的强类型指针缓存下来。
3. 「能力」维度会持续膨胀。如果你频繁需要给同一个外壳加新能力（render → hitTest → serialize → undo…），每次都要改 Concept 并波及所有 Model<T>：此时多接口（ISP 拆分）+ 动态查询（qvariant_cast 风格）或访问者模式更合适。
4. 对象生命周期天然共享/不可拷贝。如果外壳内部是 shared_ptr 语义、又要频繁拷贝，那它已经是「共享的接口指针」，直接传 std::shared_ptr<IConcept> 更直白——擦除只承诺「值语义」，不承诺「廉价拷贝」。

维度	类型擦除	策略模式 Strategy	适配器 Adapter	桥接 Bridge
多态在哪发生	外部（外壳上的 vtable）	内部（被包装类继承 Strategy）	内部（Adapter 继承 Target）	内部（Abstraction 持有 Implementor 基类）
被包装者是否需继承	不需要（鸭子类型）	需要继承 Strategy 基类	需要（Adapter 自己继承 Target）	Implementor 需要继承
是否值语义	有（可拷贝/可入容器）	通常没有（外部持有指针/引用）	视实现，通常没有	通常没有
数量关系	N 种实现 → 1 个外壳（N:1）	1 组可替换算法	1 个不兼容接口 → 1 个期望接口（1:1）	2 个维度各自独立扩展（M×N）
典型代表	std::function、std::any、QVariant、QMetaObject::invokeMethod	QTextCodec、排序比较器、QStyle	QSqlDriver 包装底层驱动、QImageReader 适配格式插件	Qt 的 QPainter（Abstraction）↔ QPaintEngine（Implementor）

与策略模式的关系最容易说混。策略模式关心「运行时换算法」，通常用指针/引用持有、生命周期由外部管；类型擦除关心「把类型与值语义一起装进外壳」，它常常是策略模式更好的存储载体：把策略从 std::unique_ptr<IStrategy> 换成值语义的擦除外壳，就同时拿到了可拷贝、可放入容器、零侵入三件套（代价是拷贝会走 clone()）。

与适配器模式的差别是「语义」。适配器做的是接口语义转换（把 QImageReader::read() 改成你期望的 load()，1 个适配器对 1 个目标）；类型擦除不改变语义，它只是把「同一契约」从继承体系里搬到外壳上，用于一次性收纳 N 种实现。换言之，Model<T> 长得像适配器，但它是由编译器批量生成的、且只为「接线」而存在。

与桥接模式的差别是「维度」。桥接显式建模两个独立变化的继承层次（抽象 vs 实现），设计者主动写出两层类；类型擦除只有一个契约维度，被包装者对结构完全无感。桥接适合「同一套操作要在多种平台上实现」（QPainter/QPaintEngine），擦除适合「同一套操作要作用于一堆既成类型」。

别忘了最大的对手：模板/C++20 概念。如果所有类型在编译期都已知、且可以接受头文件里出现实现，那么 template <Renderable T> void renderAll(const std::vector<T>&) 是零开销最优解（完全内联、无堆分配、编译期报错清晰）。模板与类型擦除不是取代关系，而是「编译期多态 ↔ 运行期多态」的分工：容器/边界/配置驱动的场合用擦除，算法/算法内部的泛化用模板。事实上标准库自己就是两者叠加——std::function 是模板构造（编译期接线）+ 虚调用（运行期分派）。

1）QVariant + QMetaType —— Qt 最著名的类型擦除。这套设计几乎可以逐行对应今天手写的三层：

• QMetaType = 运行期的 Concept 表：它给每个已注册类型保存一份「函数指针表」，含 construct / copy / move / destruct / compare / convert / debugStream，外加 size 与 alignment。本质上就是编译器帮你生成的那张 vtable，只不过 Qt 用运行期注册的方式把它做成了可查询的表。
• QVariant = Wrapper：固定大小、值语义（可拷贝）、能放进 QVariantList/QModelIndex 里；QVariant::Private 里有一个 Data union 做内联存储（int/double/bool/QString/QPoint 等小类型直接放在 QVariant 内部，指针/大对象走堆）——这就是 Qt 版的 SBO，所以 QVariant 在不同实现里往往是 16~24 字节级别的固定尺寸。
• QVariant::fromValue<T>() ≈ Model<T> 的生成：它用 QMetaType::fromType<T>() 拿到 T 的函数指针表并实例化（Q_DECLARE_METATYPE 就是让这个实例化可见的显式注册；Qt6 里许多场合已自动注册，但类型仍需可拷贝、可默认构造）。
• QVariant::value<T>()/toInt()/toString() ≈ 类型还原：擦除不是丢失，而是把类型信息挪到运行期，取用时再问一次「你其实是 int 吗」，代价是运行期检查（返回默认值而非抛异常）。

2）QObject::connect 的 functor 版本：Qt 自己写了一个 std::function。Qt5 起支持 connect(sender, &Sender::sig, context, [](){...}) 这样的「槽是任意可调用对象」。Qt 是怎么存这个 lambda 的？答案是 QtPrivate::QSlotObjectBase——一个手工实现的类型擦除外壳（源码见 qtbase/src/corelib/kernel/qobjectdefs_impl.h）：它继承自 QSlotObjectBase（带引用计数），派生模板 QSlotObject<Func, Args, R> 就相当于今天的 Model<T>，而 QSlotObjectBase 里的 impl() 函数指针就是那张「vtable」的入口。Qt 没有直接用 std::function，因为它需要额外能力：引用计数复用、连接比较（同一槽对象去重）、以及不依赖 std::function 的异常/ABI 约束。这是「同一个模式因不同工程约束写出不同实现」的绝佳案例。

3）QMetaObject::invokeMethod 与信号槽的参数传递。跨线程调用、或按名字调用（invokeMethod(obj, "slotName", Q_ARG(int, 42))）时，参数被逐个装进 void* 数组，并带上对应的 QMetaType，由元系统在目标线程里用那张函数指针表拷贝/析构它们。这就是「按名字找方法、按类型还原参数」的运行期擦除式分发——也是 Qt 能实现 queued connection 的根基。

4）QSharedPointer<T> 的删除器。它接受任意删除器（QSharedPointer<T> p(new T, [](T* p){ /* 自定义释放 */ })），而 QSharedPointer<T> 的类型不因删除器不同而改变——删除器被擦除成一个存储起来的可调用对象，析构时通过它释放。这正是「一个类型装下任意行为」在智能指针上的应用。

5）QAbstractItemModel::data() 返回 QVariant。为什么不是返回某种基类指针？因为视图（QStyledItemDelegate、QTreeView）需要对模型的任意列做统一处理：文本列是 QString、进度列是 int、图标列是 QIcon、颜色列是 QBrush。用 QVariant 一把擦除，视图才能靠 itemDelegate 与 Qt::ItemDataRole 统一渲染——这是「类型擦除腾出框架抽象空间」的教科书式例子。

代码特征信号（看到这 5 个就知道是类型擦除）：

1. template <class T> class Model final : public Concept —— 模型层是模板、且只在类外/模板里知道 T；
2. 外壳类里只有一个 std::unique_ptr<Concept>（或一张函数指针表 + 内联缓冲），sizeof 与 T 无关；
3. 类不是模板，但构造函数是模板（这是「一个类型装下任意实现」的签名特征）；
4. 拷贝构造里出现 clone() 虚调用，Concept 里必然有 clone + 虚析构；
5. 工程里出现 std::function / std::any / QVariant / QMetaObject::invokeMethod —— 都是在用别人写好的类型擦除。

三句话回顾：① 它的价值不是「多态」，而是「多态 + 值语义 + 零侵入」这三样同时成立；② 它的边界是「实现维度开放、能力维度封闭」，能力要动就得改 Concept；③ 它与模板不是替代关系，而是「运行期多态 ↔ 编译期多态」的分工，标准库自己就是两者叠加（模板接线 + 虚调用分派）。