std::future::wait_for不能用于分布式超时，因其仅阻塞等待本地任务，无法中断远程i/o；网络超时需依赖通信库自身机制（如grpc deadline）或非阻塞socket配置。
std::async + std::future.wait_for 为什么不能直接用于分布式超时？
因为 std::future::wait_for 只能阻塞等待本地任务完成，无法中断正在执行的远程调用（比如 gRPC 请求、HTTP 客户端写入、socket send/recv）。一旦底层 I/O 进入系统调用阻塞态，std::async 的线程根本不会响应 future 的超时——它还在等 TCP ACK 或服务端响应。
真实场景中，你看到的“超时”其实是客户端库自己实现的 cancel 逻辑（如 gRPC 的 deadline、libcurl 的 CURLOPT_TIMEOUT_MS），不是 C++ 标准库能插手的。
- 别把
std::future::wait_for当成万能超时开关；它只对 CPU-bound 任务有效 - 网络调用必须依赖底层通信库自身的超时或取消机制
- 若自行封装 socket，需用
setsockopt(SO_RCVTIMEO)或poll()/epoll_wait()配合非阻塞模式
如何让异步回调在超时后自动失效？
核心是避免“超时已过，回调却仍执行并修改状态”。常见错误是：注册了 on_response 回调，但没绑定生命周期控制，结果 5 秒超时后，3 秒前发的请求突然返回，回调篡改了新请求的数据。
推荐用弱引用+令牌校验模式：
立即学习“C++免费学习笔记（深入）”；
- 每个请求生成唯一
request_id，存入std::shared_ptr管理的上下文对象 - 回调函数捕获该对象的
std::weak_ptr，进入回调第一行就lock()；失败则直接 return - 超时触发时，仅销毁该
shared_ptr，不主动 kill 线程或中断 I/O
示例关键片段：
auto ctx = std::make_shared<RequestContext>();
auto weak_ctx = std::weak_ptr<RequestContext>(ctx);
start_rpc_call(..., [weak_ctx](Response r) {
auto ctx = weak_ctx.lock();
if (!ctx) return; // 已超时，忽略
ctx->handle_response(r);
});
// 超时定时器触发：
timer->after(timeout_ms, [ctx] { /* ctx 自动析构 */ });
std::chrono::steady_clock 是唯一靠谱的超时基准吗？
是。因为 std::chrono::system_clock 可能被 NTP 调整、手动修改时间，导致 wait_until 提前返回或无限等待。分布式系统里，节点间时间不同步是常态，但单机内超时必须稳定。
所有超时计算、定时器注册、重试间隔都必须基于 std::chrono::steady_clock：
-
std::this_thread::sleep_until接收steady_clock::time_point，否则行为未定义 - 自研定时器（如基于 epoll 的）必须用
clock_gettime(CLOCK_MONOTONIC)初始化 - 不要用
time(nullptr)或std::chrono::system_clock::now()做超时比较
为什么 std::promise 不适合做跨线程异步响应聚合？
std::promise 是一次性写入的，且 set_value/set_exception 只能调用一次。但在分布式容错中，你可能需要：重试多次、合并多个副本响应、降级兜底——这些都需要可多次写入、带状态判断的响应容器。
更合适的是自定义响应槽（response slot）：
- 用
std::atomic<bool></bool>标记是否已提交主响应 - 首次成功响应调用
fulfill_primary()，后续响应只进日志或监控 - 超时后调用
fulfill_fallback()，覆盖原 promise（需额外锁或 CAS 控制） - 避免直接暴露
std::promise给业务层，封装成AsyncResponseSlot<t></t>
复杂点在于：超时和响应到达的竞态必须用原子操作或 mutex 严格保护，漏掉一个 memory_order_acquire/release 就可能导致读到脏值。
