std::stop_callback仅在request_stop()调用线程执行，不跨线程广播；需共享同一std::stop_source并分发其token，且回调对象生命周期须长于线程；推荐轮询token.stop_requested()以避免生命周期管理错误。
std::stop_callback 本身不跨线程生效，它只在 request_stop() 被调用的线程中执行回调 —— 所以“多线程异步取消”不是靠它广播信号，而是靠共享同一个 std::stop_source，再把它的 get_token() 分发给各线程。
为什么 std::stop_callback 在子线程里注册却没触发？
最常见原因是：回调对象生命周期结束得太早。比如在 std::jthread 的启动函数里定义 std::stop_callback，函数返回即析构，后续调 t.request_stop() 就找不到它了。
- 错误写法：
std::jthread t([](std::stop_token token) { std::stop_callback cb(token, []{ cleanup(); }); });→cb是栈上局部变量，lambda 返回就销毁 - 正确做法：把
std::stop_callback定义在和线程同生命周期的作用域，例如类成员、或std::jthread变量声明之后的同一作用域 - 更稳妥的替代：多数场景下直接轮询
token.stop_requested()，比管理回调生命周期更简单、不易出错
多个线程响应同一个取消请求，怎么共享 stop_source？
不能依赖 std::jthread::get_stop_token() —— 它只反映本线程的停止状态，无法被其他线程监听。必须显式构造一个外部 std::stop_source，再通过 get_token() 分发。
- 先创建共享源：
std::stop_source ss; - 分发令牌给各线程：
std::jthread t1(worker, ss.get_token());、std::jthread t2(worker, ss.get_token()); - 统一触发：
ss.request_stop();→ 所有绑定该 token 的std::stop_callback（只要还活着）都会执行一次 - 注意：多个回调执行顺序无保证，别让它们互相依赖或竞争同一资源
std::stop_callback 里能做哪些事？哪些绝对不能做？
它只执行一次、不重入、不阻塞、也不改变线程状态 —— 所以设计时得克制。
- 适合做：
close()文件描述符、unlock()全局互斥量、reset()共享指针、记录日志等轻量级清理 - 禁止做：耗时 I/O（如写大文件）、等待其他线程（
join()或条件变量等待）、加锁竞争激烈资源（可能卡住整个 stop 流程） - 特别注意：回调里设的标志位（如
bool cancelled = true;），任务主体必须主动检查，否则毫无意义
真正难的从来不是写回调函数，而是确保它活得到被调用那一刻，同时不干扰主线程节奏 —— 很多崩溃都源于回调还在访问已释放的 lambda 捕获对象，或误以为它能中断正在运行的循环。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
