std::move_only_function 为什么不是 std::function 的“升级版”？

它根本不是用来替代 std::function 的——两者语义不同：std::function 要求可拷贝（CopyConstructible），而 std::move_only_function 明确放弃拷贝，只保留移动。痛点不在“功能缺失”，而在“强制拷贝开销 + 类型擦除冗余”。比如你存一个只能移动的 lambda（捕获了 std::unique_ptr），用 std::function 会编译失败；退而求其次用 std::shared_ptr<:function> 又引入引用计数和堆分配——这不是零开销。

std::move_only_function 如何实现零开销抽象？

关键在实现策略：它仍做类型擦除，但不强求拷贝，因此可以省掉拷贝相关的虚函数表项、避免为支持拷贝预留额外存储空间（如某些 libstdc++ 实现中 std::function 内置小缓冲区需对齐到拷贝安全边界）。更重要的是——它允许底层直接 move-only callable 对象（如带 std::unique_ptr 捕获的 lambda）原地构造，不经过中间包装或堆分配。

• std::function 存一个捕获 std::unique_ptr 的 lambda → 编译错误
• std::move_only_function 存同个 lambda → 合法，且通常不触发堆分配（若满足 small-buffer 条件）
• 调用开销与 std::function 相当（一次虚函数调用），但构造/移动更轻量

实际使用时最容易踩的坑

不是所有 move-only callable 都能“零开销”——是否真正避免堆分配，取决于 callable 对象大小和对齐要求，以及标准库实现的小缓冲区容量（通常是 24 或 32 字节）。一旦溢出，仍会 fallback 到堆分配。

• 别假设“move-only 就一定栈上存”：检查 sizeof 和你的 STL 实现文档（如 libc++ 的 __small_size）
• 不能传给需要 CopyConstructible 的接口：例如 std::thread 构造函数接受右值但内部会 move，没问题；但 std::vector::push_back 若反复扩容，可能需要重排元素——此时若 vector 元素是 std::move_only_function，则要求其可移动，而非可拷贝，这是 OK 的；但若误传给期望 std::function 的 API（如某些老库回调注册函数），编译直接失败
• 没有 target() 或 target_type()：因为 move-only erase 后无法安全反向还原类型，所以运行时类型查询能力被主动舍弃

auto f = [p = std::make_unique(42)]() mutable {
    std::cout << *p << "\n";
    p = nullptr;
};
std::move_only_function fn = std::move(f); // OK
// std::function fn2 = std::move(f); // ERROR: copy constructor of 'f' is deleted