std::stop_callback是“有人喊停了”的通知铃，仅在request_stop()被调用时触发一次轻量回调，其生命周期必须覆盖整个任务周期，否则易导致ub；推荐优先轮询stop_requested()而非使用stop_callback。
std::stop_callback 不是中断开关，而是“有人喊停了”的通知铃。它不终止线程，也不影响执行流，只在 request_stop() 被调用时触发一次回调 —— 前提是这个回调还活着。
std::stop_callback 的生命周期必须撑到 stop 请求发生
最常见的崩溃来源：把 std::stop_callback 定义成任务函数内部的局部变量。
- 回调对象在函数返回时立即析构，而此时
std::jthread可能还在运行 - 后续调用
request_stop()会尝试调用已销毁对象的回调，UB（未定义行为） - 尤其危险的是捕获了局部
std::stop_token引用，或在 lambda 中引用了栈上变量
正确做法是让 std::stop_callback 的生存期覆盖整个任务周期：
- 作为类成员变量（配合
std::jthread成员） - 定义在
std::jthread启动之前的作用域（如函数开头） - 或者直接不用它——多数场景下，在任务循环里调
token.stop_requested()更简单可靠
std::stop_callback 里不能做阻塞或耗时操作
它的执行上下文是发出 request_stop() 的那个线程，不是工作线程本身。
- 如果在回调里调
close(socket_fd)或std::mutex::lock()，可能引发死锁或显著拖慢取消响应 - 回调不重入、不排队、不等待；一旦执行完就彻底失效
- 标准不保证多个
std::stop_callback的执行顺序，也不保证是否并发执行
推荐只做轻量、无锁、幂等操作：
- 设置一个
std::atomic<bool></bool>标志位（但注意：这和轮询stop_requested()是重复劳动） - 发一条日志（用 lock-free 日志库）
- 调用
std::condition_variable::notify_all()唤醒等待线程（前提是该 cv 不在销毁中）
std::stop_callback 和 std::jthread 构造顺序搞反会静默失效
错误写法：
std::jthread t([](std::stop_token token) {
std::stop_callback cb(token, []{ cleanup(); }); // ❌ 局部变量，函数退出即析构
while (!token.stop_requested()) {
do_work();
}
});
问题在于：回调注册后还没等 request_stop()，lambda 已返回，cb 析构，后续调用 t.request_stop() 不会触发任何回调。
正确写法之一（显式管理）：
std::stop_source source;
std::stop_callback cb(source.get_token(), []{ cleanup(); });
std::jthread t([source]{ /* 使用 source.get_token() */ });
// cb 生存期长于 t，确保能被触发
更推荐的做法是放弃 std::stop_callback，直接在任务中轮询：
- 逻辑集中，调试直观
- 避免生命周期错位风险
- 能自然嵌入 I/O 等待点（如
std::this_thread::sleep_for()内部可响应 stop）
真正容易被忽略的点是：std::stop_callback 的触发时机完全取决于 request_stop() 的调用时刻，而不是任务当前执行到哪。如果你的任务正在系统调用中阻塞（比如 read()），而你又没在回调里做唤醒动作，那它不会“立即响应”——协作式取消从来就不是抢占式的，它依赖你在合适位置主动检查。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
