std::stop_callback无法直接支持超时，因其无内置计时器，仅响应显式request_stop()调用；需组合外部定时器、共享stop_source和任务内轮询检查点三者协同实现。
要让异步请求在超时后自动撤回，不能依赖 std::stop_callback 自身实现计时功能，它对时间毫无感知，只响应显式 request_stop() 调用；必须手动组合外部定时器、统一的 std::stop_source 和任务内轮询检查点，三者缺一不可。
为什么 std::stop_callback 无法直接支持超时
std::stop_callback 没有内置计时器，不会在指定毫秒后自动触发任何操作。它只做一件事：当绑定的 std::stop_token 所关联的 std::stop_source 被显式调用 request_stop() 时，在 request_stop() 所在线程上下文中执行一次轻量函数。
常见误解是起一个 std::thread 睡 5 秒后调 t.request_stop()，再在 std::jthread 的 lambda 里声明 std::stop_callback——但该 callback 是 lambda 局部变量，函数返回即析构，request_stop() 到来时对象已销毁，静默失效。
真正起作用的是你写的那个“睡完就 request_stop”的线程，不是 std::stop_callback 本身。
立即学习“C++免费学习笔记（深入）”；
构建可工作的超时撤回协作模型
第一步：声明长期存活的外部 std::stop_source
在全局作用域或类成员位置声明 static std::stop_source g_timeout_source; —— 【必须确保其生命周期覆盖整个超时窗口，不能是栈局部变量】
第二步：将 token 分发给工作线程
启动 std::jthread 时，显式传入 g_timeout_source.get_token()，而非使用 t.get_stop_token()。后者来自 jthread 私有 stop_source，外部定时器无法对其广播。
第三步：在工作线程中注册回调并轮询状态
在工作函数内部，用接收到的 token 构造 std::stop_callback，并在循环顶部、每次 I/O 前或每处理一个数据包后插入 if (token.stop_requested()) return; —— 这才是任务主动退出的关键路径，仅靠 callback 不足以撤回正在运行的逻辑。
第四步：启动独立定时器线程触发撤回
起一个新线程（如 std::thread 或 std::jthread），调用 std::this_thread::sleep_for(5s) 后执行 g_timeout_source.request_stop();。注意：这里调用的是 g_timeout_source.request_stop()，不是任意 jthread 实例的 request_stop()。
std::stop_callback 在超时场景中能写什么
方法一：置原子标志 + 通知等待方
done_flag.store(true, std::memory_order_relaxed); cv.notify_one(); —— 这类操作轻量、无锁、不阻塞，适合在 request_stop() 所在线程中执行。
方法二：解锁共享互斥量
shared_mutex.unlock(); —— 仅限已加锁且确定未被其他线程持有锁的场景，否则可能引发未定义行为。
方法三：记录原子日志
log_counter.fetch_add(1, std::memory_order_relaxed); —— 避免格式化字符串、文件写入等 I/O 操作。
【禁止在回调中调用 std::ofstream::close()、std::mutex::lock()、sleep_for() 或任何可能阻塞的系统调用】 因为它运行在定时器线程上下文中，不是工作线程，阻塞会导致整个撤回流程挂起。
验证信号是否真正传播成功
在 std::stop_callback 的 lambda 主体中加入一句 std::cout
不要依赖异常或返回值判断回调是否执行——它不抛异常、不返回状态，执行与否完全取决于对象是否存活且 token 有效。
把 std::stop_callback 声明在 std::jthread 变量之后、同一作用域内，例如：std::jthread t(fn); std::stop_callback cb(g_timeout_source.get_token(), []{ std::cout —— 这是最小可行的存活保障方式。
