std::async 默认启动策略是 lazy 还是 eager？
默认是 std::launch::deferred | std::launch::async，也就是“由实现决定”——但绝大多数主流标准库（libstdc++、libc++、MSVC STL）在默认调用 std::async(func) 时，**实际走的是 async 模式（立即派生线程）**，不是 lazy。这点常被误解为“惰性求值”，其实不是。
关键在于：只要没调用 future.get() 或 future.wait()，任务可能还没开始执行；但线程**很可能已经创建并运行中了**——这取决于调度器和系统负载，不是你可控的延迟。
- 不显式指定策略时，行为不可移植，不能假设为 deferred
- 若想确保延迟执行，必须写成
std::async(std::launch::deferred, func) - 若想强制并发（且禁止 deferred），用
std::async(std::launch::async, func)
std::async 启动失败时会怎样？常见崩溃点在哪里？
最典型的情况是系统线程数超限或资源不足，此时 std::async(std::launch::async, ...) 可能抛出 std::system_error，错误码为 std::errc::resource_unavailable_try_again 或 std::errc::operation_not_permitted。
注意：std::launch::deferred 永远不会启动线程，所以不会因资源失败；但调用 get() 时才真正执行，这时可能抛出函数内部异常（非系统级）。
立即学习“C++免费学习笔记（深入）”；
- 未捕获
std::system_error会导致程序 terminate - 多个
std::async短时间内密集调用，容易触发资源限制（尤其在嵌入式或容器环境） - Linux 上可通过
/proc/sys/kernel/threads-max查看上限，ulimit -u限制进程级线程数
如何避免 std::async 的隐式等待和生命周期陷阱？
std::future 析构时，若状态为 deferred，会**同步阻塞等待执行完成**；若为 async，则仅释放资源，不等待——但很多人误以为所有情况都不阻塞，结果在作用域结束时卡住主线程。
更隐蔽的问题是：把 std::async 返回的临时 std::future 绑定到右值引用（如 auto&& f = std::async(...)），仍无法延长其生命周期；C++17 起，临时对象绑定到 const lvalue 引用才能延长，但 future 不是 const。
- 务必显式保存 future 对象：用
auto f = std::async(...)，而非直接调用后丢弃 - 避免在函数返回前让 future 被析构（尤其 deferred 模式下）
- 不要依赖“不保存 future 就不执行”——async 模式下任务早已启动，只是结果无人读取
auto f = std::async(std::launch::async, []{
std::this_thread::sleep_for(2s);
return 42;
});
// 此处任务已在后台运行
int result = f.get(); // 阻塞直到完成
std::async 和 std::thread 在线程管理上根本区别是什么？
std::async 管理的是「异步操作的值」，不是线程本身；它不提供 join/detach 接口，也不让你控制线程生命周期。而 std::thread 是对 OS 线程的轻量封装，必须显式管理（否则析构时 terminate）。
这意味着：std::async 更适合“发个任务，之后取结果”的场景；不适合需要长期驻留、反复通信、或精细控制线程状态（如暂停、优先级、亲和性）的场合。
-
std::async无法设置线程名（Linux 用pthread_setname_np，Windows 用SetThreadDescription），std::thread可以 -
std::async不支持移动到另一个作用域（future 可移动，但执行上下文绑定在原 async 调用点） - 大量短任务用
std::async易造成线程频繁创建销毁，开销大；应考虑线程池 +std::packaged_task
实际用的时候，最容易忽略的是 deferred 模式下 future 析构的隐式同步，以及 async 模式下无节制调用引发的系统级资源耗尽——这两点既不报编译错，也难在测试中暴露，上线后才突然卡死或崩溃。