std::stop_callback 不支持超时自动撤回，因其无内置计时器，仅响应显式 request_stop()；需手动组合外部 stop_source、定时器和轮询检查点实现协作撤回。
std::stop_callback 本身不支持超时自动撤回，它只响应 request_stop() 的显式调用；所谓“超时撤回”必须由你手动组合定时器、std::stop_source 和轮询检查点来实现。
为什么 std::stop_callback 不会因超时自动触发
std::stop_callback 对时间毫无感知：没有内置计时器，不会在指定毫秒后自动调用 request_stop()。它只做一件事——当绑定的 std::stop_token 所关联的 std::stop_source 被显式调用 request_stop() 时，在回调构造所在线程上下文中执行一次轻量函数。
常见静默失效链路：
- 把
std::stop_callback声明在std::jthread启动 lambda 内部 → lambda 返回即析构，超时信号来时对象已销毁 - 用
t.get_stop_token()构造回调 → 该 token 来自std::jthread私有std::stop_source，外部定时器无法对其广播 - 超时线程和工作线程持有不同
std::stop_source实例 → 信号发错地方，彼此不可见 - 回调捕获了栈上
std::mutex或局部std::ofstream引用 → 回调执行时引用悬空，触发未定义行为
如何安全组合超时与 stop_callback 实现协作撤回
关键不是让 std::stop_callback 做超时，而是确保超时触发的 request_stop() 能被正确接收并响应。这要求三者同步就位：
立即学习“C++免费学习笔记（深入）”；
- 使用外部统一、长期存活的
std::stop_source（如static std::stop_source g_timeout_source;或类成员），确保它比所有依赖它的线程活得更久 -
std::stop_callback必须声明在g_timeout_source之后、且与工作线程同生命周期（例如：和std::jthread变量在同一作用域中顺序声明） - 工作线程函数里不能只靠
std::stop_callback，必须持续调用token.stop_requested()—— 比如在每次网络读取前、每处理一个数据包后、或循环顶部插入if (token.stop_requested()) return; - 超时线程应调用
g_timeout_source.request_stop()，而不是工作线程的t.request_stop()（后者只对其私有std::stop_source有效）
std::stop_callback 在超时场景中该做什么、不该做什么
它运行在超时线程（调用 request_stop() 的线程）上下文中，不是工作线程，因此必须严格满足轻量、无锁、无阻塞约束：
- ✅ 允许：
done_flag.store(true, std::memory_order_relaxed)、cv.notify_one()、shared_mutex.unlock()、记录原子日志 - ❌ 禁止：
close(fd)、ofstream::flush()、mutex.lock()、std::this_thread::sleep_for()、网络调用 —— 这些都可能阻塞，且不在工作线程上下文
真正起作用的是你写的那个“睡完就 request_stop()”的线程，不是 std::stop_callback 本身；它的唯一职责是：当 request_stop() 到来时，执行一次轻量回调（比如置标志、发通知），仅此而已。
最容易被忽略的复杂点
超时撤回不是“注册一个回调 + 启动定时器”就能跑通的线性流程。它本质是三个独立生命周期的协同：定时器线程的启动/退出时机、std::stop_source 的生存期边界、以及每个 std::stop_callback 实例的构造/析构位置。三者只要有一处错位（比如 std::stop_source 是栈变量、std::stop_callback 在 lambda 内声明、或工作线程漏掉 stop_requested() 检查），整个机制就静默失效——既不报错，也不触发，只留下一个永远卡住的任务。
