std::stop_callback 不支持超时自动撤回，因其无内置计时器且仅响应显式 request_stop()；超时需手动组合定时器、外部 stop_source 和轮询检查点实现。
std::stop_callback 本身不支持超时自动撤回，它只在 std::stop_source::request_stop() 被显式调用时执行一次轻量回调；所谓“超时撤回”必须由你手动组合定时器、std::stop_source 和轮询检查点来实现。
为什么 std::stop_callback 不会因超时自动触发
std::stop_callback 对时间毫无感知，没有内置计时器，也不会在指定毫秒后自动调用 request_stop()。它只响应绑定的 std::stop_token 所关联的 std::stop_source 的显式通知。
常见错误是：起一个 std::thread 睡 5 秒后调 t.request_stop()，再在 std::jthread 的 lambda 里声明 std::stop_callback——但该 callback 是 lambda 局部变量，函数返回即析构，request_stop() 到来时对象已不存在，静默失效。
真正起作用的是那个“睡完就 request_stop”的线程，不是 std::stop_callback 本身。
超时撤回必须用外部 std::stop_source 统一广播
单个任务的超时控制不能依赖 std::jthread 自带的私有 std::stop_source，否则定时器线程和工作线程根本不在同一个信号域里。
- 声明
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 在超时场景中该做什么、不该做什么
它运行在调用 request_stop() 的线程上下文中（通常是定时器线程），不是工作线程，因此必须严格满足轻量、无锁、无阻塞约束。
✅ 允许操作：
done_flag.store(true, std::memory_order_relaxed)cv.notify_one()shared_mutex.unlock()- 记录原子日志（如
std::atomic<int> log_count{0}</int>）
❌ 禁止操作：
-
close(fd)（可能阻塞，且 fd 可能已被工作线程关闭） -
ofstream::flush()、sleep_for()、网络调用 -
mutex.lock()（极易死锁，尤其当工作线程正持有该锁）
任务主循环里不轮询 stop_requested() 就等于没取消机制
std::stop_callback 是“通知器”，token.stop_requested() 才是“执行开关”。两者必须配合使用，缺一不可。
轮询点必须插在关键位置：
- 长循环顶部：
if (token.stop_requested()) return; - 阻塞 I/O 前：
if (token.stop_requested()) break;再调read()或recv() - 每次处理完一个数据包后检查
- 不要依赖
std::jthread自动处理——它只对std::this_thread::sleep_for等少数函数提供中断点，你自己写的忙等或系统调用不会响应
最容易被忽略的是：回调对象必须比 request_stop() 调用早构造、晚析构，且不能跨线程析构；哪怕逻辑全对，只要 std::stop_callback 实例提前销毁，整个超时撤回就彻底失效。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
