c++23的std::move_only_function解决了std::function的什么痛点？ (零开销抽象)

c++kquote>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> 又引入引用计数和堆分配——这不是零开销。

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

零开销不体现在“完全没成本”，而在于它把成本控制在 move-only 语义所必需的最小集合里——不为不存在的需求（拷贝）买单，也不因规避拷贝而引入新成本（如 shared_ptr 包装）。真正难的是判断你的 callable 是否够小、是否真能避开堆。