std::function会堆分配是因为其内部小缓冲区（通常16–32字节）不足以容纳较大可调用对象，需fallback到堆上存储；这是为支持任意大小捕获列表和签名而做的设计权衡。
为什么 std::function 会堆分配
std::function 在目标可调用对象（比如 lambda、绑定表达式）尺寸超过内部小缓冲区（通常 16–32 字节，取决于标准库实现）时，会 fallback 到堆上 new 一块内存来存放。这不是 bug，是设计权衡：它要支持任意大小的捕获列表和任意调用签名。但如果你的回调对象始终很小（例如只有几个 int 或指针捕获），且你明确知道生命周期可控，那堆分配就成了纯开销。
用 std::aligned_storage + union 手动管理栈内存储
核心思路是：预设一个固定大小的栈缓冲区（比如 32 字节），用 std::aligned_storage_t 确保对齐，再用 union 或 placement new + 析构函数手动管理对象的构造/析构。关键不是“不分配”，而是“不调用 new/delete”。
- 选大小要保守：
sizeof(void*) * 4（32 字节）能容纳大多数带 2–3 个捕获变量的 lambda，但别硬塞std::string或大数组 - 必须显式调用析构：在 wrapper 析构或重赋值前，用
obj_ptr->~T()销毁旧对象，否则捕获资源泄漏 - 不能直接用 union 存异构类型（C++17 前 union 不支持非 trivial 类型），推荐用
char buffer[32]+ placement new - 调用签名需固定，比如只支持
void()或int(int)—— 多态靠模板参数，不是运行时擦除
template<typename Sig>
class stack_function;
<p>template<typename R, typename... Args>
class stack_function<R(Args...)> {
static constexpr size_t CAPACITY = 32;
alignas(max_align<em>t) char storage</em>[CAPACITY];
bool has<em>obj</em> = false;</p><pre class='brush:php;toolbar:false;'>template<typename F>
void construct_(F&& f) {
if constexpr (sizeof(F) <= CAPACITY && std::is_trivially_destructible_v<F>) {
new (storage_) F(std::forward<F>(f));
has_obj_ = true;
} else {
// 超出容量或非平凡析构 → 静态断言或拒绝编译
static_assert(sizeof(F) <= CAPACITY, "Callable too large for stack_function");
}
}public: template<typename F> stackfunction(F&& f) { construct(std::forward<F>(f)); }
R operator()(Args... args) const {
return reinterpret_cast<const std::function<R(Args...)>&>(storage_)(std::forward<Args>(args)...);
// ⚠️ 实际中这里要存函数指针+this指针，不是 reinterpret_cast！见下条
}};
真正可行的简化版：只存函数指针 + void* thisptr
如果你的回调都是无状态函数、静态成员函数，或你愿意把捕获数据手动打包进 void*（比如传入对象地址），那根本不需要存储整个 callable 对象。这是最轻、零分配、零模板爆炸的做法，也是嵌入式/实时系统常用模式。
立即学习“C++免费学习笔记（深入）”；
- 签名固定为
R(*)(Args..., void*)，最后一个void*是用户传入的上下文指针 - 构造时只存两个字段：
func_ptr_（函数指针）和ctx_ptr_（void*）—— 共 16 字节（64 位平台） - 调用时：
return func_ptr_(std::forward<Args>(args)..., ctx_ptr_); - lambda 要用 [&] 捕获？不行。得写成普通函数 + 把 this 或数据地址作为
ctx_ptr_传进去 - 优势：大小确定、无异常、无对齐烦恼、编译快；劣势：牺牲了语法糖，不能直接绑定局部变量
别忽略移动语义和异常安全边界
即使不用堆，stack_function 的移动构造/赋值仍可能隐含问题：如果源对象持有 non-trivial 类型（如 std::unique_ptr 捕获），而你只 memcpy 了 buffer，就会 double-delete。所以要么禁止这类类型（static_assert(!std::is_polymorphic_v<F>)），要么要求 F 必须 trivially copyable。
- 移动操作不能只
memcpy—— 要先析构源，再 placement new 到目标，再标记源为无效 - 如果允许抛异常（比如构造时 F 的构造函数抛异常），就得确保 buffer 中对象处于“已析构”状态，否则栈展开时会崩
- 最稳妥的底线：只接受
std::is_trivially_copyable_v<F>且sizeof(F) <= CAPACITY的类型
真正零成本的回调包装器，本质是放弃通用性换确定性。你得清楚自己要封装什么、谁负责生命周期、能不能接受多一个 void* 参数——这些决策点比代码行数重要得多。
