std::stop_callback超时失效主因是生命周期管理不当或stop_token不统一；须用外部长期存活的std::stop_source分发token，回调仅做轻量通知，避免阻塞操作。
注册了 std::stop_callback 却没触发超时撤回逻辑？不是回调写错了，而是它根本没活到 request_stop() 被调用那一刻——生命周期断在了线程启动前，或者回调里干了不该干的事。
std::stop_callback 在超时场景下为何常“静默失效”
超时撤回本质是外部控制流（比如定时器线程）调用 source.request_stop()，但 std::stop_callback 是否响应，只取决于两件事：它是否还活着、它绑定的 std::stop_token 是否有效。常见失效链路：
- 把
std::stop_callback声明在std::jthread构造的 lambda 内部 → 线程函数一返回就析构，超时信号来时对象已销毁 - 用
t.get_stop_token()创建回调，但该 token 来自std::jthread自带私有std::stop_source→ 外部定时器无法对其广播，request_stop()根本不生效 - 超时定时器和任务线程持有不同
std::stop_source实例 → 信号发错地方，彼此不可见 - 回调捕获了局部
std::ofstream或栈上std::mutex引用 → 回调执行时引用已悬空，UB 风险
超时撤回必须用外部 std::stop_source 统一广播
单个任务的超时控制，不能依赖 std::jthread 自带的 stop source；必须由超时管理者（如定时器线程或主控类）持有长期存活的 std::stop_source，再分发 token 给所有参与者。
-
static std::stop_source g_timeout_source;或作为类成员（非局部变量），确保其生命周期覆盖整个超时窗口 - 任务线程接收的是
g_timeout_source.get_token()，不是t.get_stop_token() - 超时触发时，统一调用
g_timeout_source.request_stop()，所有绑定该 token 的std::stop_callback才可能被唤醒 - 若需区分“超时”与“主动取消”，可在回调中检查额外标志（如
std::atomic<bool> timeout_flag{false}</bool>），由定时器线程置位后调用request_stop()
std::stop_callback 里只能做轻量、无阻塞的撤回通知
超时路径要求低延迟、高确定性，回调若卡住，整个撤回流程就挂起。它不是任务主逻辑的替代品，而是“通知出口”。
立即学习“C++免费学习笔记（深入）”；
- ✅ 允许操作：
done_flag.store(true, std::memory_order_relaxed)、cv.notify_one()、shared_mutex.unlock()、记录原子日志 - ❌ 禁止操作：
close(fd)、ofstream::flush()、mutex.lock()、sleep_for()、网络调用——这些都可能阻塞，且不在工作线程上下文中执行 - ⚠️ 注意：回调运行在调用
request_stop()的线程上下文（通常是定时器线程），不是你的工作线程；别在里面访问仅工作线程拥有的资源 - 多个回调绑定同一 token 时，执行顺序不确定，不要让它们互相等待或依赖状态
比 std::stop_callback 更稳的超时撤回方案：轮询 + sleep_for
对绝大多数异步请求超时场景，直接在任务循环中轮询 token.stop_requested() 比注册回调更可靠、更易调试、也更少出错。
- 用
std::this_thread::sleep_for()替代usleep()或忙等 —— 它能响应std::stop_token，睡眠期间收到超时信号会提前退出 - 长计算段拆成小块，每处理 N 项后插一句
if (token.stop_requested()) return; - I/O 前加判断：
if (token.stop_requested()) break;，再调read()或send() - 避免把超时逻辑耦合进回调；任务自身掌握“何时可中断”，比外部通知更精准
最难的不是实现超时，而是确保那个 std::stop_callback 实例在超时信号发出的瞬间仍有效，且它做的第一件事不是去关文件，而是立刻通知工作线程自己该停了——后者才是撤回真正发生的地方。
