std::future未析构会导致主线程卡住，因其析构函数会阻塞等待任务完成；常见原因包括绑定到引用、存入容器未清理、移动后误用等，需主动调用get()或wait()确保析构。
async 返回的 std::future 没析构，主线程就卡住
这是最典型的症状：程序看似“卡死”在 main() 结束处，或在 std::async 调用后某处 hang 住。根本原因不是线程没结束，而是 std::future 对象未被销毁 —— 它的析构函数会阻塞等待异步任务完成（除非你显式调用 wait() 或取值），而如果这个 future 是临时对象（比如没绑定到变量），它本该在语句末尾析构，但若被意外延长生命周期（如绑定到引用、被移动后残留空壳），就可能漏掉析构时机。
- 常见错误写法：
auto&& f = std::async(...);——auto&&延长临时future生命周期，但后续没调用f.wait()或f.get()，析构仍会阻塞，且容易误以为“已托管” - 更隐蔽的情况：把
std::future存进容器（如std::vector<:future>></:future>）但忘了清空或遍历等待，容器析构时才逐个阻塞，导致退出慢 - 注意：
std::launch::deferred模式下，future析构不触发执行，但get()或wait()才真正调用 —— 如果永远不调，任务根本不跑，也不报错
怎么快速定位哪个 future 没被释放
靠日志或断点效率低。直接用地址 sanitizer + UB sanitizer 编译运行，能捕获部分未定义行为，但对“未析构”无感。更有效的是加轻量级跟踪：
- 给
std::future包一层可追踪 wrapper（仅调试期），在构造/移动/析构时打日志，例如用全局计数器 +std::cout << "future ctor #" << ++g_future_cnt << "\n"; - 在
main()结尾前加断点，用调试器查看栈上或全局存活的std::future对象（GDB 中info variables future不行，但可搜索std::future类型的局部变量或 watch 成员指针） - Linux 下可检查进程是否还有未 join 的线程：
ps -T -p $(pidof your_program)，如果线程数异常多且std::async用的是std::launch::async，大概率是 future 阻塞导致线程卡在~future()内部的wait_for()调用
std::future 移动后原对象状态必须检查
移动一个 std::future 后，原对象进入有效但空（valid-but-empty）状态，其 valid() 返回 false。如果之后又对它调用 get() 或 wait()，会抛 std::future_error（错误码 no_state）。但这不是“没析构”，而是误用；真正的问题常出现在移动后忘记检查，还把它当作可用对象存进容器或传参。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 错误示例：
auto f1 = std::async(...); auto f2 = std::move(f1); f1.get(); // crash - 安全做法：移动后立即置空或重置，或用
if (f.valid()) f.wait();包裹所有操作 - 注意：
std::shared_future不可移动（拷贝构造），不会出现此问题，但开销更大
别依赖 RAII 自动析构，主动管理生命周期
RAII 在这里不可靠 —— 临时 future 看似自动析构，但一旦绑定到引用、放进容器、或被 lambda 捕获，生命周期就脱离预期。生产代码中，应明确谁负责等待、谁负责取值。
立即学习“C++免费学习笔记（深入）”；
- 原则：每个
std::async调用，必须有且仅有一个地方调用get()或wait()，且确保该调用一定被执行（比如放在finally逻辑里，或用std::unique_ptr+ 自定义 deleter 封装） - 避免裸用临时 future：
std::async(...).get();是 OK 的（临时对象生命期延续到完整表达式结束，get()强制等待并析构）；但std::async(...).wait();不推荐，因为没取值，任务结果丢弃，且无法判断是否成功 - 调试期可在
future析构函数里加断点（GDB 中break std::future<int>::~future），看是否真被调用 —— 如果断点从不触发，说明对象还在栈/堆上活着，得回溯声明位置
最难发现的是跨作用域传递 future 时隐式延长生命周期，比如返回局部 future 给调用方却没文档说明“你得自己 get()”，这种契约模糊最容易埋雷。
