最安全的方式是用 std::mutex 保护 std::queue，入队出队均 std::move std::function；std::promise/std::future 适合一次性结果通知；避免用 std::thread::id 分发、勿依赖 std::launch::deferred 实现异步回调。
std::function + std::queue 怎么安全传递回调到主线程
直接把 std::function 对象从工作线程塞进队列、再由主线程取出来调用，是最轻量也最可控的方式。关键不是“怎么传”，而是“怎么保证不崩”——核心是加锁 + 移动语义。
常见错误现象：std::function 被拷贝多次后内部可调用对象析构，或多个线程同时读写同一队列导致 segmentation fault；更隐蔽的是，没用 std::move 导致回调被意外复制，而原对象又持有独占资源（比如 std::unique_ptr 参数）。
- 用
std::mutex保护共享队列，避免裸push/pop - 入队时用
std::move(cb)，出队后立即std::move给局部变量再调用 - 别在回调里做耗时操作；如果必须，把它再派发到另一个线程，而不是卡住主线程
- 队列类型推荐
std::queue<:function>></:function>，别用std::vector模拟队列（erase(begin())效率低且易错）
std::promise/std::future 怎么用于一次性的跨线程结果通知
当工作线程只需要“告诉主线程一件事完成了，并带一个返回值”，std::promise 比队列更干净。它本质是单次写入、单次读取的同步信道，天然规避了重复消费或竞争问题。
使用场景：网络请求完成、文件读取结束、异步计算得出结果。不适合高频回调（比如每毫秒一次的传感器数据），因为每个 std::promise 只能 set_value 一次，反复 new/promise/future 开销大。
- 主线程创建
std::promise<t></t>，取出std::future<t></t>后把std::promise移动到工作线程（通过std::thread构造参数或std::async） - 工作线程处理完后调用
promise.set_value(result)或promise.set_exception(...) - 主线程用
future.wait()阻塞，或future.wait_for(...)轮询，再调用future.get()取值（注意：get()只能调一次） - 如果主线程不能阻塞（如 GUI 线程），就别用
wait()，改用定时器轮询wait_for(0s)判断状态
为什么不要直接用 std::thread::id 做线程间函数分发
std::thread::id 是只读标识，本身不提供任何调度能力。有人试图缓存主线程 ID，在工作线程里判断 “如果是主线程就直接调，否则发消息”，这是错的——工作线程永远 ≠ 主线程，这个判断恒为 false；更糟的是，有些平台（如 Windows）主线程 ID 在线程池中可能复用，导致误判。
真正需要的是“目标线程是否在运行消息循环”或“是否有可用的执行上下文”，这层抽象不在标准库里。Qt 有 QMetaObject::invokeMethod，Windows 有 PostMessage，Linux GUI 常依赖 GLib 的 g_idle_add。C++ 标准库只管线程生命周期，不管事件分发。
- 别在代码里写
if (std::this_thread::get_id() == main_id)来“优化”回调路径 - 所有跨线程调用，统一走队列或 promise，哪怕主线程收到后立刻同步执行——一致性比微小性能更重要
- 若真要零拷贝高性能回调（如实时音频），得脱离
std::thread，用平台特定的 waitable timer 或 completion port，但这就不是“C++ 多线程”而是系统编程了
std::async 启动的任务怎么把回调交还给指定线程
std::async 默认用线程池或新线程执行，但它不负责回调派发。它的 std::future 只能由调用 get() 或 wait() 的线程来同步获取结果，无法自动“触发主线程某个函数”。想实现“async 完事自动调 UI 更新”，你仍然得手动把 std::future 和一个主线程可访问的队列/信号机制绑定。
容易踩的坑：用 std::launch::deferred 以为能延迟到主线程执行，结果发现 get() 一调才真正运行——这不是回调，是同步懒加载，工作逻辑仍卡在主线程里。
- 接受
std::async返回的std::future，然后在主线程的更新循环（如游戏主循环、GUI idle handler）里定期检查future.wait_for(0s) == std::future_status::ready - 或者把
std::future包进一个std::function<void></void>，放进前面说的主线程安全队列，由主线程取出来调get() - 别依赖
std::launch::deferred实现异步效果；它只是推迟执行时机，不改变执行线程
跨线程回调真正的复杂点从来不在语法，而在所有权移交的时机和异常传播路径——比如工作线程抛了异常，你是让 std::promise 捕获它，还是通过队列发一个错误 std::function，抑或直接终止整个流程？这些决策比选哪个 API 更影响系统稳定性。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
