std::function调用比函数指针慢的根本原因是类型擦除导致的间接跳转和额外内存访问，而非泛型开销；其operator()无法内联，且可能引发堆分配，而函数指针是直接call指令。
std::function 调用比函数指针慢的根本原因
慢在类型擦除带来的间接跳转和额外内存访问，不是“泛型开销”或“模板膨胀”问题。它必须通过内部存储的函数对象指针 + 调用包装器（通常是虚函数或函数指针数组）完成调用，而原生函数指针是直接 call 指令。
常见错误现象：std::function 在 tight loop 里被反复调用时，性能明显低于等价的函数指针或 lambda（未捕获时）；std::function 对象大小远大于函数指针（通常 16–32 字节 vs 8 字节），影响缓存局部性。
- 底层实现依赖小对象优化（SOO），但即使 SOO 命中，调用路径仍需查表或条件跳转
- 无法被编译器内联 ——
std::function::operator()是虚分发或间接函数调用，编译器看不到实际目标 - 若绑定的是捕获 lambda 或
std::bind结果，还会引入额外堆分配（SOO 失败时），进一步拖慢构造和析构
什么场景下 std::function 的开销可以接受
当调用频率低、或抽象价值远高于微秒级损耗时，比如事件回调、插件接口、配置化策略注册。这时候你不是在“用 std::function 替代函数指针”，而是在用它解决类型不一致的问题。
使用场景举例：GUI 框架中注册按钮点击处理函数；测试框架中保存不同签名的 fixture 函数；解析配置后动态选择算法策略。
立即学习“C++免费学习笔记（深入）”；
- 调用间隔 > 数百纳秒（例如用户交互、IO 触发、定时器回调）—— 开销占比可忽略
- 需要统一持有 void()、int(int)、void(const std::string&) 等不同签名的可调用体
- 目标可调用体生命周期由
std::function管理（如捕获 lambda），函数指针做不到这点
如何避免无谓的 std::function 性能损失
不是所有地方都需要 std::function。能用模板参数传 callable 的，优先用模板；能用函数指针的，别包一层 std::function。
常见错误：把 std::function<void></void> 当作“通用回调类型”到处塞，哪怕只接收无捕获 lambda 或普通函数。
- 对固定签名且调用频繁的热路径，用模板参数：
template<typename f> void run(F&& f)</typename> - 若必须运行时多态，且签名统一、无捕获，优先考虑函数指针（
void(*)()）或成员函数指针（配合对象指针） - 构造
std::function时避免隐式转换：显式写std::function{[](){}}而非some_func([](){})（后者可能触发多次拷贝/移动） - 注意
std::function的移动构造是廉价的，但拷贝构造可能触发堆分配（尤其 SOO 失败时）
std::function 和函数指针的 ABI 与兼容性差异
函数指针是 C ABI 级别稳定的东西，std::function 是 C++ 标准库实现细节 —— 不同 STL 版本（libstdc++ / libc++ / MSVC STL）内部结构不同，不能跨 DLL/so 边界传递 std::function 对象。
错误现象：std::function 作为 DLL 导出函数的参数或返回值，在 Windows 上可能崩溃；在 Linux 上链接时看似正常，运行时因 vtable 偏移或内存布局不一致而 segfault。
- 函数指针可安全用于 C 接口、dlopen/dlsym、跨编译器 ABI（如 clang/gcc 混用）
-
std::function构造函数接受函数指针，但反向不可行：无法从std::function安全提取原始函数指针（除非你知道它确实存的是函数指针且没捕获） - 调试时，
std::function在 gdb/lldb 中显示为黑盒，而函数指针可直接打印地址并 disassemble
std::function::operator() 都绕不开一次间接跳转 —— 这个事实很容易被“它用起来很顺”的直觉掩盖。 
