std::move_only_function不是std::function的升级版，因其语义不同：前者要求可移动但不可拷贝，后者要求可拷贝；它通过省略拷贝相关虚函数表项、避免对齐冗余、支持原地构造move-only callable实现零开销抽象，但堆分配与否取决于对象大小与标准库小缓冲区容量。
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></:function> 又引入引用计数和堆分配——这不是零开销。
std::move_only_function 如何实现零开销抽象？
关键在实现策略：它仍做类型擦除，但不强求拷贝，因此可以省掉拷贝相关的虚函数表项、避免为支持拷贝预留额外存储空间（如某些 libstdc++ 实现中 std::function 内置小缓冲区需对齐到拷贝安全边界）。更重要的是——它允许底层直接 move-only callable 对象（如带 std::unique_ptr 捕获的 lambda）原地构造，不经过中间包装或堆分配。
-
std::function<void></void>存一个捕获std::unique_ptr<int></int>的 lambda → 编译错误 -
std::move_only_function<void></void>存同个 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<int>(42)]() mutable {
std::cout << *p << "\n";
p = nullptr;
};
std::move_only_function<void()> fn = std::move(f); // OK
// std::function<void()> fn2 = std::move(f); // ERROR: copy constructor of 'f' is deleted
零开销不体现在“完全没成本”，而在于它把成本控制在 move-only 语义所必需的最小集合里——不为不存在的需求（拷贝）买单，也不因规避拷贝而引入新成本（如 shared_ptr 包装）。真正难的是判断你的 callable 是否够小、是否真能避开堆。 
