std::function不支持SSO因标准未强制要求，主流实现默认无稳定SSO；手动实现需联合体+小缓冲区（如24字节）+类型擦除函数指针，并谨慎处理捕获lambda与成员函数的存储和析构。
std::function 为什么不能直接用于 SSO 场景
因为 std::function 内部实现通常包含堆分配（即使目标可调用对象很小），它不保证小对象优化（SSO）——标准未规定其实现必须支持 SSO，主流 libstdc++ 和 libc++ 都默认不启用或仅对极小闭包（如无捕获 lambda）做有限优化，且不可控。你无法靠换编译器或标准库版本来稳定获得 SSO 行为。
手动实现 SSO 包装器的关键结构设计
核心是用联合体（union）+ 小缓冲区 + 类型擦除函数指针，把可调用对象的值或指针存进固定大小的栈空间里。典型做法是预留 24 或 32 字节（兼顾常见指针/整数/简单 lambda 的尺寸），并用一个 enum class 标记当前存储状态（in-place / heap / empty）。
- 缓冲区大小建议设为
sizeof(void*) * 3（即 24 字节），能容纳多数无捕获 lambda、std::function对象本身（libc++ 中约 24 字节）、单个成员函数指针加对象指针 - 必须显式管理生命周期：在析构时根据 tag 调用对应类型的
~T()；移动构造/赋值时需正确转移并置空源对象的缓冲区 - 类型擦除函数指针（如
void (*invoke)(const void*, Args&&...)）不能是虚函数，避免 vtable 开销，也绕过继承体系
如何安全支持捕获 lambda 和成员函数
关键不是“能不能存”，而是“怎么存得干净”。捕获 lambda 若含非 trivial 类型（如 std::string），必须确保其完整布局能放进缓冲区，否则触发 fallback 到堆分配。成员函数则需拆解为 obj_ptr + memfn_ptr，二者合起来不超过缓冲区容量（x86_64 下各 8 字节，共 16 字节，安全）。
- 对带捕获的 lambda，先用
sizeof(T)和std::is_trivially_destructible_v<t></t>判断是否可 in-place 构造；否则退到new T(std::move(t)) - 不要尝试把
std::bind结果塞进去——它内部可能已堆分配，且类型不可知，破坏 SSO 前提 - 调用操作符
operator()必须通过统一 invoke 函数跳转，该函数从缓冲区中按 tag 提取原始地址并 cast 后调用
性能与 ABI 兼容性容易被忽略的点
SSO 包装器的真正代价不在调用开销（现代 CPU 分支预测很好），而在于缓存局部性破坏和指令 cache 占用。每次构造/移动都涉及 24 字节 memcpy，比纯指针传递重；若频繁拷贝大闭包（哪怕没越界），反而更慢。
立即学习“C++免费学习笔记（深入）”；
- 禁止将 SSO 包装器作为函数参数值传入 hot path —— 改用
const&或移动语义（auto&&）避免冗余复制 - 不要把它暴露给动态链接边界（如 DLL / so），因为缓冲区布局、invoke 函数签名、tag 枚举定义一旦变动就 ABI 不兼容
- 调试时注意：GDB 可能无法自动识别 union 中活跃字段，需手动 cast 指针查看，例如
(MyWrapper::storage_t*) &w
实际项目中，SSO 包装器的价值只在明确热点路径（如事件循环中每帧创建数千个回调）且对象普遍 ≤24 字节时才显著。否则，先 profile 再动手。
