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