正确做法是协作式取消，核心为std::stop_source、std::stop_token和std::stop_callback三件套；需立即响应阻塞调用取消时必须用std::stop_source而非bool标志，因后者无法穿透系统调用。
不能靠全局 flag + 轮询，也不能用 suspend/resume —— 正确做法是协作式取消，核心是 std::stop_source、std::stop_token 和 std::stop_callback 三件套。
什么时候必须用 std::stop_source 而不是自己写 bool 标志
当你需要线程在阻塞调用（比如 cv.wait()、std::this_thread::sleep_for()）中**立即响应取消**时，自定义 bool 标志完全失效。因为线程卡在系统调用里，根本不会检查标志位。
-
std::stop_token可被传入支持协作中断的等待函数（如cv.wait(lock, token, pred)），一旦request_stop()被调用，它会自动唤醒并返回 false，无需轮询 - 全局
bool+std::mutex不仅代码臃肿，还容易漏加锁、错加锁，且无法穿透阻塞点 -
std::stop_source是唯一能触发这种“唤醒+退出”语义的标准机制，且线程安全，无需额外同步
std::jthread 怎么让停止逻辑自动触发
std::jthread 的价值不在“启动”，而在“析构时自动 request_stop() 并 join()”。你只需在它的启动函数里注册清理动作，就能确保资源一定被释放。
- 在
std::jthread启动函数内，用传入的std::stop_token构造std::stop_callback，例如：std::stop_callback cb{stoken, []{ fclose(fp); }} - 不要把
std::stop_callback存为类成员或跨线程传递 —— 它绑定的是当前线程的 token，移动后原实例失效 - 如果回调要捕获外部资源（如文件指针、锁对象），必须保证该资源生命周期长于
jthread：推荐用std::shared_ptr管理，并按值捕获智能指针
为什么 std::stop_callback 不能替代手动清理检查
std::stop_callback 是单次、异步、不可重入的清理入口，它不负责“判断是否该停”，只负责“停之后必须做的事”。它和轮询 stop_requested() 是互补关系，不是二选一。
- 轮询
stoken.stop_requested()用于决定工作循环是否提前退出（比如释放中间状态、保存进度） -
std::stop_callback用于兜底：哪怕轮询漏了一次、线程正卡在系统调用里，只要 stop 被 request，它就一定会被执行一次 - 常见错误是只注册 callback 却不轮询 —— 导致任务继续执行无效工作，甚至破坏数据一致性
取消后资源没释放？先查这三点
最常被忽略的不是语法，而是资源生命周期与 token 绑定时机的错配。
- 回调里捕获的
FILE*或裸指针，其指向对象是否在线程退出前已被销毁？例如局部变量、已 move 出作用域的std::unique_ptr -
std::stop_callback实例是否定义在栈上，而所在作用域早于线程函数返回？它必须活到线程真正结束 - 是否误把
std::stop_token当作“取消信号发生器” —— 它只是状态视图，真正发起取消的是std::stop_source::request_stop()
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
