std::future超时不会取消任务，需协作式取消；C++20用std::jthread+std::stop_token实现安全中断；网络请求需分层处理超时、连接错误与HTTP状态码；共享资源须同步保护。
std::future 等待超时后无法自动取消任务？这是设计使然
std::future 本身不提供取消能力，wait_for 或 wait_until 超时只代表“还没就绪”，底层线程/任务仍在运行。强行 kill 线程是未定义行为，所以必须从任务内部支持协作式取消——也就是传入 std::stop_token（C++20）或自定义取消标志（C++11/14/17）。
用 std::jthread + std::stop_token 实现可中断的异步请求任务
C++20 的 std::jthread 自带 std::stop_source，配合 std::stop_token 可安全通知任务退出。典型模式是：在异步任务中定期检查 token.stop_requested()，一旦为真就提前返回或清理资源。
- 不要在线程函数里直接调用
std::this_thread::sleep_for做长等待，改用token.wait_until（C++20）或带超时的条件变量等待 - 网络 I/O 层需支持非阻塞或可中断：比如 libcurl 可设
CURLOPT_TIMEOUT_MS，asio 使用async_wait配合steady_timer - 示例片段（简化版）：
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, 5000L);
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)};
// ... 后续用 t.request_stop() 触发取消
重试逻辑不能只靠 try/catch，要区分错误类型
网络请求失败分三类：std::future_status::timeout（等待 future 超时）、底层请求失败（如 DNS 错误、连接拒绝）、业务层 HTTP 状态码异常（如 503）。这三者重试策略完全不同：
- 等待 future 超时 → 说明任务还在跑，此时应先
request_stop()再启动新任务，避免堆积 - curl 返回
CURLE_COULDNT_CONNECT→ 可重试，但需指数退避（如 100ms → 200ms → 400ms） - HTTP 状态码为 401 或 403 → 重试无意义，应直接失败并透出认证错误
- 建议用枚举封装错误类型，避免字符串匹配或 magic number
std::future 与定时器组合时，别让 timer 和 task 竞争资源
常见错误是用一个 std::thread 启动定时器，超时后调 request_stop()；但若任务正在修改共享状态（如写日志、更新计数器），而定时器线程也去读，就可能触发 data race。
立即学习“C++免费学习笔记（深入）”；
- 所有跨线程访问的变量必须加锁（
std::mutex）或用原子类型（std::atomic_bool） - 更安全的做法：把重试控制逻辑收拢到单一线程（比如用 asio 的
io_context统一调度 timer 和 http 请求） - 如果坚持手写 timer，推荐用
std::condition_variable::wait_until配合std::unique_lock，而非轮询 + sleep
真正难的不是拼出代码，而是理清「谁负责取消」「谁负责释放资源」「超时判断发生在哪一层」——这三个问题没想清楚，加再多 std::future 和 std::chrono 也还是会卡死或泄漏。
