<p>函数指针作回调时类型必须严格匹配，包括调用约定、参数类型与数量、返回值；静态成员函数可直接使用，普通成员函数需通过void* user_data传递this，lambda仅无捕获时可转函数指针，std::function更灵活但有开销。</p>
函数指针作为回调参数时，类型声明必须严格匹配
传给第三方库或自定义函数的回调，不是随便写个 void func() 就能塞进去的。编译器会检查调用约定、参数个数、类型和返回值——哪怕只差一个 const 或 int vs long，都会报错，比如：error: cannot convert 'void (*)()' to 'void (*)(int)' in assignment。
常见做法是先定义类型别名，避免写一长串函数指针语法：
using CallbackFunc = void (*)(int, const char*);<br>void register_handler(CallbackFunc cb); // 接收回调
- 如果原函数带
this（即非静态成员函数），不能直接传——它隐含第一个参数this，类型不兼容 - 使用
std::function可以绕过限制，但有额外开销；纯 C 风格 API（如 Windows API、libuv）只认裸函数指针 - Windows 上注意调用约定：
__stdcall和__cdecl不互通，错误会导致栈不平衡、崩溃
静态成员函数可以当回调，但普通成员函数不行
类内定义的普通成员函数自带 this 参数，其类型本质是 void (MyClass::*)(int)，和 void (*)(int) 是不同类型。而静态成员函数没有 this，签名完全等价于普通函数。
示例：
立即学习“C++免费学习笔记（深入）”；
class Logger {<br>public:<br> static void on_log(int level, const char* msg) { /* OK */ }<br> void instance_log(int level, const char* msg) { /* 不可直接作回调 */ }<br>};<br><br>// 正确注册<br>register_handler(&Logger::on_log);- 若必须用实例状态，常见解法是把
this通过用户数据参数传入（如很多 C API 的void* user_data） - 不要试图用
reinterpret_cast强转成员函数指针——行为未定义，多数平台直接 crash - lambda 表达式只有不捕获变量时才能转成函数指针：
[](int x){...}✅，[&]{...}❌
回调函数里调用对象方法，得靠 void* 传参解耦
绝大多数 C 风格回调接口允许附带一个 void* user_data 参数，在回调触发时原样返还。这是把对象实例“带进去”的标准方式。
例如 libuv 或 SQLite 的典型模式：
struct Task {<br> int id;<br> void run() { /* 实际逻辑 */ }<br>};<br><br>void uv_timer_cb(uv_timer_t* handle, int status) {<br> Task* task = static_cast<Task*>(handle->data);<br> task->run(); // 安全调用<br>}- 务必确保
user_data指向的对象生命周期长于回调注册期，否则访问野指针 - 别在回调里 delete 对象，除非你 100% 控制调用时机和线程上下文
- 多线程环境下，
user_data所指对象需自行加锁，函数指针本身不提供线程安全
用 std::function 包装回调更灵活，但要注意性能和存储位置
现代 C++ 中，std::function 能容纳函数指针、lambda、绑定表达式甚至成员函数，适合内部模块间传递回调。
但要注意：
std::function<void(int)> cb = [](int x) { printf("%d\n", x); };<br>// 或<br>cb = std::bind(&MyClass::method, &obj, std::placeholders::_1);- 小 lambda（无捕获）可能被
std::function内联存储；一旦捕获变量，就会 heap 分配，带来额外开销 - 频繁调用的热路径（如图形渲染每帧回调）慎用
std::function，优先选裸函数指针 - 不能把
std::function直接传给要求void(*)(...)的 C API——必须另设一层静态转发函数
真正麻烦的地方不在语法，而在生命周期管理和线程安全——函数指针本身很轻量，但背后的数据谁管、什么时候失效、在哪条线程上执行，这些才是实际项目里反复踩坑的点。
