std::future/std::promise无法传播超时，应使用自定义deadline_context类封装steady_clock::time_point并提供remaining()和is_expired()方法，通过std::packaged_task+lambda按值捕获其shared_ptr实现级联传递。
std::future 和 std::promise 无法传播超时，别硬套
标准库的 std::future 没有超时传递机制，wait_for 或 wait_until 只作用于当前 future，下游任务完全感知不到上游设的 deadline。强行用 std::chrono::steady_clock::now() 手动算剩余时间再传参，极易因时钟漂移、调度延迟或多次转发导致误差累积——实际超时比预期早几十毫秒，或者压根不触发。
真正能承载上下文（含截止时间）的是 std::shared_ptr 包裹的结构体，或更推荐：自定义的 deadline_context 类，内部存 std::chrono::steady_clock::time_point，并提供 remaining() 方法返回 std::chrono::nanoseconds。
- 不要把
std::chrono::steady_clock::now()当“当前时间”直接减——它本身有开销，且在多线程中不同线程调用时刻不同 - 超时点应统一由父任务初始化，子任务只读取、只调用
remaining()，不重新计算 - 若子任务需发起新异步操作（如网络请求），必须把
remaining()结果转为对应 API 的 timeout 参数（比如 libcurl 的CURLOPT_TIMEOUT_MS）
用 std::packaged_task + lambda 捕获 deadline_context 实现级联
关键不是“怎么启动异步”，而是“怎么让每个环节都天然持有截止信息”。std::packaged_task 支持绑定任意 callable，用 lambda 捕获 deadline_context 的 shared_ptr 最自然：
auto ctx = std::make_shared<deadline_context>(std::chrono::steady_clock::now() + 500ms);
std::packaged_task<int()> task([ctx]() {
if (ctx->is_expired()) return -1;
// 实际工作
return do_work_with_timeout(ctx->remaining());
});
这里 do_work_with_timeout 是你封装的带超时逻辑的函数，它内部会把 ctx->remaining() 转成具体 IO 或计算的约束。注意：lambda 必须按值捕获 ctx（即 [ctx]），否则父 context 生命周期结束会导致子任务访问 dangling pointer。
立即学习“C++免费学习笔记（深入）”；
- 如果子任务还要 spawn 孙任务，就 new 一个新
deadline_context，构造时传入ctx->deadline()（而非remaining()），避免嵌套调用中反复减法误差 - 所有耗时操作前必须先调
ctx->is_expired()，不能只依赖最后的remaining()返回值——因为remaining()可能返回负数，但你得提前退出 - 别用
std::async直接包装，它不支持传入自定义上下文；必须用std::thread或 executor 配合std::packaged_task
std::jthread + stop_token 不解决超时传播问题
std::jthread 的 stop_token 是协作式取消，和“还有多少时间”无关。它只能告诉你“该停了”，但不知道为什么停、还剩几毫秒、是否来自上游超时。如果你的子任务正在等锁、等条件变量、或做不可中断的 CPU 计算，stop_token 根本不会生效。
真实场景中，超时必须转化为可测量、可比较、可传递的时间点（time_point），而不是布尔信号。把 stop_token 和 deadline_context 混用是常见误区——前者管“是否允许继续”，后者管“还能撑多久”，二者要正交设计。
- 不要在
stop_callback里重置 deadline 或修改 context，这破坏单向传播原则 - 如果底层库只接受
stop_token（如某些 C++20 executor），那就用deadline_context启动一个 watchdog 线程，在到期时调request_stop() - Windows 上
WaitForSingleObject或 Linux 的epoll_wait等系统调用，timeout 参数必须来自remaining()转换，不能硬写 100ms
级联超时最易被忽略的边界：时钟精度与线程唤醒延迟
即使代码逻辑全对，std::chrono::steady_clock 在不同平台分辨率差异很大：Linux glibc 通常 1ns，Windows QueryPerformanceCounter 理论上也高，但实际调度器可能 15ms 才唤醒一次线程。这意味着你设了 20ms 超时，任务可能在 35ms 后才被通知过期。
所以“级联”不是数学上的精确传递，而是逐层保守衰减：父任务设 500ms，子任务拿到后立即检查 is_expired()，若未过期，再扣掉 1~2ms 安全余量作为自己的 deadline，再往下传。这个余量不是拍脑袋，而是根据你线程池的平均唤醒延迟实测得出。
- 不要假设
std::this_thread::sleep_for(1ms)真睡满 1ms；它可能 15ms 后才返回，这期间你的 deadline 已悄悄过期 - 所有
time_point必须用std::chrono::steady_clock，绝不用system_clock（它可能被 NTP 调整） - 日志里记 deadline 时，记
time_point.time_since_epoch().count()，别记字符串格式化结果——方便后续用脚本比对各环节偏差
