std::future::wait_for 不取消任务，仅等待结果就绪；超时后任务仍运行，需用 std::jthread + std::stop_token 协作式取消，配合 libcurl 超时与分层错误处理实现安全重试。
直接说结论：std::future::wait_for 本身不取消任务，重试必须配合协作式取消（如 std::stop_token）或手动线程管理；裸用 wait_for + get() 只会卡住或堆积僵尸线程。
std::future::wait_for 超时后任务还在跑？这是设计使然
std::future::wait_for 超时只代表“结果还没就绪”，底层线程/任务仍在执行。你无法靠它中断任务——C++ 标准没赋予 std::future 取消能力。强行 std::thread::join 或 detach 已运行线程是未定义行为。
- 常见错误现象：连续调用
std::async重试，但前几次任务仍在后台跑，CPU 占用飙升、内存泄漏、连接堆积 - 正确做法：任务函数内部必须检查取消信号，比如 C++20 的
std::stop_token，或自定义std::atomic<bool></bool>标志 - 网络请求场景下，还要分层处理：libcurl 设置
CURLOPT_TIMEOUT_MS控制单次请求超时，std::jthread::request_stop()控制整个任务生命周期
用 std::jthread + std::stop_token 实现可中断重试
C++20 提供了安全的协作式取消原语：std::jthread 自带 std::stop_source，构造时自动绑定 std::stop_token，任务中定期轮询即可退出。
- 不要在任务里写
std::this_thread::sleep_for(5s)—— 这会阻塞取消响应；改用token.wait_until(steady_clock::now() + 5s) - 重试逻辑必须放在主线程（或控制线程）中：超时后调用
t.request_stop()，再启动新std::jthread - 示例关键片段：
auto task = [](std::stop_token token, std::string url) -> std::string { auto handle = curl_easy_init(); curl_easy_setopt(handle, CURLOPT_URL, url.c_str()); curl_easy_setopt(handle, CURLOPT_TIMEOUT_MS, 3000L); while (!token.stop_requested()) { CURLcode res = curl_easy_perform(handle); if (res == CURLE_OK) break; if (res == CURLE_OPERATION_TIMEDOUT) continue; } curl_easy_cleanup(handle); return token.stop_requested() ? "" : "success"; }; std::jthread t{task, std::move(url)};
重试策略不能只看 wait_for 返回值
网络请求失败有三层含义，每层需不同响应：std::future_status::timeout（等待超时）、底层 I/O 错误（如 CURLE_COULDNT_CONNECT）、HTTP 状态码（如 503）。混为一谈会导致无效重试或掩盖真实问题。
立即学习“C++免费学习笔记（深入）”；
-
std::future_status::timeout→ 先request_stop()再启新任务，避免堆积 -
CURLE_COULDNT_CONNECT或CURLE_COULDNT_RESOLVE_HOST→ 可重试，建议加指数退避（base_delay * (1LL ），上限设 <code>max_delay_ms = 5000 - HTTP 401/403/429 → 直接失败，重试无意义；503 可重试但应限流
- 所有时间计算必须用
std::chrono::steady_clock，system_clock可能被 NTP 调整，导致退避间隔错乱
condition_variable::wait_for 不适合做任务级超时控制
std::condition_variable::wait_for 是为线程间同步设计的，不是任务调度器。它的精度受系统调度影响，Linux 下平均误差 1–4ms，Windows 下可达 15ms；且它不关联任何执行体，无法触发取消逻辑。
- 别用它等一个异步任务完成——这属于职责错位；它适合等“共享状态变更”，比如
bool ready = true - 若硬要用，必须配
std::unique_lock和完整谓词检查，否则可能虚假唤醒后继续执行错误逻辑 - 真正需要高精度或可取消的任务超时，应组合
std::jthread+steady_clock::time_point+ 手动轮询，或用 asio 的steady_timer配合async_wait
最易被忽略的一点：重试不是简单循环，它必须携带上下文——当前重试次数、起始时间戳、上次错误类型、是否已 request_stop。把这些塞进一个结构体传入，比零散传 5 个参数更安全，也方便后续加 jitter 或熔断逻辑。
