std::future::get()未捕获异常会直接调用std::terminate导致程序崩溃；因异步任务抛出的异常被封装在共享状态中，get()时重新抛出，若无try-catch则触发终止，且析构不自动处理异常。
std::future::get() 不捕获异常会直接终止程序
调用 std::future::get() 时，如果关联的异步任务（比如 std::async 启动的）抛出了未被处理的异常，该异常不会自动传播到主线程——而是被存储在 future 对象内部。一旦你调用 get()，这个异常会被重新抛出；如果你没用 try/catch 捕获，就会触发 std::terminate，进程直接退出，连堆栈都不打。
常见现象：程序在某次 get() 调用处静默崩溃，gdb 显示停在 __cxxabiv1::__terminate，std::thread::join() 或 main 返回前就挂了。
- 即使异步任务里只有一行
throw std::runtime_error("oops")，只要没在get()外围 catch，就必崩 -
std::future的析构不会自动 rethrow 异常，但get()是唯一能取值/取异常的入口，错过它就永远丢弃异常（或等下次 get 崩） - 用
std::launch::deferred时，get()实际是同步执行函数体，异常行为一致
如何安全地调用 future::get()
核心原则：每次 get() 都必须配对 try/catch，且要捕获 std::exception 及其子类，不能只 catch 具体类型（比如只 catch std::runtime_error）。
示例：
立即学习“C++免费学习笔记（深入）”；
auto fut = std::async(std::launch::async, []{ throw std::logic_error("bad arg"); });
try {
auto result = fut.get(); // 这里会 rethrow
} catch (const std::exception& e) {
std::cerr << "Async task failed: " << e.what() << "\n";
// 继续执行，不退出
}
- 不要依赖
fut.wait_for(...)来“避免异常”——wait_for 只管超时，不管异常；异常仍会在后续get()中爆发 - 若需区分成功/失败逻辑，可封装为
std::optional<T>+ 异常日志，而不是让上层裸调get() - 多个 future 一起 wait 时（如
std::experimental::when_all），每个get()仍需独立 try/catch
future 对象生命周期管理不当也会引发问题
std::future 是**可移动不可复制**的，且一个 future 只能调用一次 get()。重复调用、移动后还访问、或提前析构都可能造成未定义行为，间接掩盖异常问题。
- 把
future存在局部作用域却忘了get()？它析构时不报错，但异常被永久丢弃——看似没事，实则掩盖了逻辑缺陷 - 用
std::shared_future时，所有副本共享同一个异常状态，任一副本get()都会 rethrow，其他副本再get()就抛std::future_error（错误码std::future_errc::no_state） - 把
future成员变量声明为std::unique_ptr<std::future<T>>？没必要，反而容易漏掉get()调用时机
调试时怎么快速定位是哪个 future 导致崩溃
崩溃点在 std::future::get() 内部，调用栈往往只显示标准库帧，看不出是哪段业务代码触发的。需要主动加线索。
- 在
std::async的 lambda 或函数开头加日志，例如：LOG(INFO) ，和 future 对象绑定 ID - 用 RAII 包装 future，构造时记录位置（文件/行号），析构或 get 前打印上下文
- GDB 中停在
terminate后，用info registers和bt full查看是否残留异常对象地址，部分 libc++/libstdc++ 实现会把异常指针存在寄存器里 - 启用 libstdc++ 的异常跟踪（编译时加
-D_GLIBCXX_DEBUG）可让 future 相关误用更早暴露
最麻烦的情况不是异常本身，而是有人把 future 当成“带返回值的 thread.join()”，忽略了它本质是个异常容器——漏掉一次 get() 或一次 catch，就等于埋了个随时会炸的定时器。
