首选 std::function + std::bind 或 lambda 实现回调，统一处理各类可调用对象；需注意 this 生命周期、避免裸指针误用、慎用 SOO 及异常，C 兼容场景用函数指针+void*。
用 std::function + std::bind 组合最稳妥
现代 C++ 实现回调，首选 std::function 作为类型擦除容器，配合 std::bind 或 lambda 捕获上下文。它能统一处理普通函数、成员函数、lambda，且语义清晰、生命周期可控。
常见错误是直接传裸函数指针却忽略 this 指针——成员函数不能隐式转成 void(*)()；还有人用 auto 推导 std::function 类型，导致模板推导失败或类型不匹配。
-
std::function<void></void>是标准签名，别写成std::function<void></void>除非真要修改原值（可能引发悬垂引用） - 绑定成员函数时，
std::bind(&MyClass::onEvent, this, std::placeholders::_1)中的this必须有效，避免绑定后对象已析构 - lambda 捕获建议显式：
[this]{ /*...*/ }比[=]更安全，防止意外拷贝大对象或捕获已失效指针
类成员函数做回调必须解决 this 生命周期问题
成员函数本身不是可调用对象，必须绑定实例。但若把回调存进异步队列、信号槽或第三方库（如 libuv、Boost.Asio），就极易出现“回调触发时对象已销毁”的崩溃。
典型现象是程序在回调执行时访问非法内存，gdb 显示栈帧中 this 是野指针，或者 ASan 报 heap-use-after-free。
立即学习“C++免费学习笔记（深入）”；
- 用
std::shared_ptr管理对象生命周期，绑定时捕获shared_from_this()，确保回调触发期间对象仍存活 - 避免在构造函数里注册回调——此时派生类虚函数表可能未就绪，
dynamic_cast或虚函数调用会出错 - 第三方库若只接受 C 风格函数指针（如
void(*)(void*)），必须额外提供静态包装器，并把this通过void*透传，此时需自行保证void*解引用安全
用函数指针实现简单回调适合嵌入式或 C 兼容场景
当目标平台无 STL、或需对接 C 接口（如 POSIX signal handler、Windows API 回调），就得退回裸函数指针 + void* 用户数据模式。
这种写法零开销，但完全失去类型安全：参数个数、顺序、生命周期全靠人工对齐，void* 强转稍有不慎就是未定义行为。
- 函数签名必须严格匹配，例如 Windows 的
WNDPROC是LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM)，少一个CALLBACK（即__stdcall）在 x86 上就栈失衡 -
void* user_data传入的对象，若为栈变量或临时对象，回调触发时早已析构；应优先传new出的堆对象，或由调用方明确管理其生命周期 - 不要在裸函数指针回调里抛异常——C ABI 不处理 C++ 异常，会导致
std::terminate
性能敏感场景慎用 std::function 的小对象优化（SOO）
std::function 内部通常有约 16–32 字节的 SOO 缓冲区，能避免小 lambda 的堆分配。但一旦捕获内容超出缓冲（比如捕获了 std::string 或 std::vector），就会触发堆分配，带来额外开销和缓存不友好。
高频回调（如音频处理每毫秒调用数百次）中，这种分配可能成为瓶颈，valgrind --tool=callgrind 可观察到明显 malloc 热点。
- 用
std::function前先确认捕获对象大小：sizeof(lambda)可在编译期检查；若 >16 字节，考虑改用函数指针 + 手动上下文指针 - 避免在循环内反复构造
std::function对象，应提前构造并复用；成员函数绑定也尽量在初始化阶段完成，而非每次事件触发时重绑 - 极端情况可用
boost::function或自定义轻量级可调用包装器（仅支持特定签名），但需权衡维护成本
回调最难的从来不是语法怎么写，而是谁拥有回调逻辑、谁负责销毁、以及跨线程时的同步边界——这些不会在编译器报错里体现，但会在凌晨三点的 core dump 里反复出现。
