std::exception_ptr是C++跨线程传递异常的标准且唯一安全方式，它通过弱引用捕获异常对象并支持线程安全传递，主线程需调用std::rethrow_exception才能捕获；手动使用时须避免生命周期问题与重复抛出，而std::async/std::future已自动封装该机制。
std::exception_ptr 是跨线程传递异常的唯一标准方式
C++ 标准不支持在线程外直接“捕获”另一个线程抛出的异常——catch 只对当前栈帧有效。想让主线程感知子线程的异常，必须显式把异常对象“搬出来”，而 std::exception_ptr 就是为此设计的句柄。它不持有异常副本，也不触发拷贝构造，只是对异常对象的弱引用（类似智能指针但不管理生命周期），且线程安全。
常见错误是试图用全局变量或 std::shared_ptr<:exception></:exception> 手动包装异常：前者有竞态风险，后者无法还原原始类型（丢失 dynamic_cast 能力），且可能引发未定义行为。
- 子线程中必须在
catch(...)块内调用std::current_exception()获取std::exception_ptr - 该指针可安全地通过值传递、存入容器、跨线程共享（如写入
std::atomic<:exception_ptr></:exception_ptr>或带锁队列） - 主线程拿到后，用
std::rethrow_exception(ptr)在当前上下文中重新抛出——此时才能被catch捕获
典型场景：std::async 和 std::future 的自动异常传播
多数情况下你不需要手动处理 std::exception_ptr，因为 std::async + std::future 已封装好整套逻辑。只要子任务抛异常，future.get() 会原样 rethrow，且保证只抛一次。
注意陷阱：std::future 必须被析构或显式调用 get() / wait()，否则异常永远不会被传递；若忘记调用 get() 就丢弃 future，异常对象会泄漏（C++11/14 中未定义行为，C++17 起明确要求终止程序）。
立即学习“C++免费学习笔记（深入）”；
- 使用
std::launch::async确保真正异步执行（默认策略可能延迟到get()时才同步运行） -
future.wait_for(...)不会 rethrow 异常，必须调用get()才触发 - 多个线程同时对同一
future调用get()是未定义行为——future是一次性消费的
手动跨线程传递时如何避免悬挂和重复抛出
手动用 std::exception_ptr 时，最易忽略的是异常对象的生命周期。如果子线程 catch 到异常后立即退出，而主线程稍晚才调用 std::rethrow_exception，原始异常对象可能已被销毁——但 std::exception_ptr 本身仍有效，因为标准要求其内部已深拷贝异常对象（通过 std::exception::what() 等接口可验证）。
真正危险的是重复 rethrow：同一个 std::exception_ptr 被多次传给 std::rethrow_exception 是允许的，但若在不同线程并发调用，且异常类型含非线程安全成员（如自定义异常里有裸指针或静态缓存），就可能崩溃。
- 推荐将
std::exception_ptr存入线程安全容器（如std::queue加std::mutex）或原子变量（std::atomic<:exception_ptr></:exception_ptr>，C++20 起支持） - 主线程取到后立即
std::rethrow_exception并处理，不要长期持有或复制多份 - 若需记录异常信息而非立即处理，用
std::exception_ptr::operator bool()判空，再调用std::current_exception()获取当前线程的异常指针做日志（不 rethrow）
为什么不能用信号或 setjmp/longjmp 跨线程跳转
std::thread 的每个线程有独立栈，setjmp 保存的栈环境只在同一线程内有效；跨线程 longjmp 会破坏目标线程栈帧，导致未定义行为（常见表现是段错误或静默数据损坏）。POSIX 信号（如 pthread_kill）也不能用来“中断并捕获异常”，因为 C++ 异常不是信号，两者机制完全隔离。
有人尝试用 std::condition_variable 配合标志位模拟“异常通知”，但这样丢失了异常类型、堆栈信息和 what() 描述，退化为普通错误码处理，违背了异常语义。
- 所有跨线程控制流转移都必须走标准库提供的同步原语（
std::promise/std::future、std::exception_ptr、锁+条件变量） - 第三方库如 Boost.Thread 的
boost::future提供更丰富的异常传播选项，但底层仍是std::exception_ptr - 调试时若发现异常“消失”，优先检查是否漏掉了
future.get()或std::rethrow_exception()调用
真正麻烦的从来不是怎么传异常，而是决定在哪个线程、什么时机、以什么粒度去响应它——比如一个后台下载线程抛了网络异常，主线程是弹窗提示、静默重试，还是直接终止整个工作流？这些业务逻辑没法靠语言机制解决，std::exception_ptr 只负责把火种安全递到你手里。
