std::async 启动后立即返回，不保证延迟执行；若需延时，须将 sleep_for 置于 lambda 内部最前，并确保 future 生命周期足够长，否则任务可能被取消或资源失效；它不是定时器，仅用于异步启动。
std::async 启动后立刻返回，根本不会等 delay
很多人写 std::async(std::launch::async, []{ std::this_thread::sleep_for(2s); do_work(); })，以为这样就实现了“2秒后执行”，结果发现 do_work() 立刻被调用——因为 std::async 只负责启动线程，不控制执行时机。
真正要延迟，得把 sleep_for 放在 lambda 内部最前面，且必须确保线程有足够生命周期（比如不立即丢弃 std::future）：
auto fut = std::async(std::launch::async, [] {
std::this_thread::sleep_for(2s);
do_work();
});
但这里仍有隐患：如果 fut 是局部变量且函数很快结束，程序可能在 do_work() 执行前就退出（尤其在调试或单元测试中）。更稳妥的做法是显式等待或分离线程，但分离又带来资源管理风险。
用 std::thread + sleep_for 更可控，但别忘了 detach 或 join
直接起线程做延迟，逻辑清晰、无 std::future 生命周期干扰：
立即学习“C++免费学习笔记（深入）”；
std::thread([]{
std::this_thread::sleep_for(3s);
do_work();
}).detach();
注意三点：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
detach()后线程独立运行，主线程无需等待，但你必须确保do_work()所依赖的资源（如全局对象、单例、静态变量）在整个延迟期间有效； - 若
do_work()用到局部变量（比如捕获了栈上引用），detach()会导致悬垂引用——必须用值捕获或确保生命周期； - 频繁创建/分离短命线程有开销，不适合高频定时（如每 10ms 一次），此时应复用线程 + 循环 + 条件变量。
chrono 时间单位写错是常见崩溃源头
写 sleep_for(2) 编译不过，但写成 sleep_for(2ms) 或 sleep_for(std::chrono::milliseconds(2)) 才对。错误示例：
-
sleep_for(2000)→ 缺少单位，实际是 2000 纳秒（几乎不延时）； -
sleep_for(2s)需要using namespace std::literals，否则报错； - 跨平台时慎用
steady_clock::now() + 5s做轮询判断，Windows 上steady_clock分辨率可能只有 15ms，导致延迟不准。
推荐统一用 std::chrono::milliseconds 显式构造，避免字面量歧义：
std::this_thread::sleep_for(std::chrono::milliseconds(2000));
真异步定时任务该用什么？别硬套 std::async
std::async 本质是“异步启动”，不是“定时调度器”。要做可取消、可重复、多任务共存的定时逻辑，应该：
- 用
std::thread跑一个事件循环，配合std::condition_variable和优先队列（按触发时间排序）； - 每个定时任务封装为
std::function<void></void>+ 触发时间点，插入队列； - 循环中
wait_until到最近任务时间，唤醒后执行并重新计算下一次； - 需要取消时，标记任务为失效（避免锁竞争），或用
std::atomic<bool></bool>控制执行开关。
硬塞 std::async 做定时，等于把调度逻辑甩给调用方，容易漏掉异常处理、重复触发、内存泄漏等问题。
真正难的不是“怎么延时”，而是“怎么让延时可靠、可维护、可观察”——比如没日志、没超时保护、没错误回调的任务，在生产环境里基本等于黑盒。
