std::stop_callback不触发的主因是生命周期不匹配：它构造即注册、析构即注销，若在request_stop()前已销毁（如定义于局部作用域），则回调永不执行。
std::stop_callback 本身不跨线程，也不会自动让其他线程响应取消；它只在 request_stop() 被调用的那一刻、且对象仍存活时，在调用方线程中执行一次回调。
std::stop_callback 为什么总不触发？
最常见现象是：调了 source.request_stop()，但注册的回调函数完全没执行。这不是 bug，而是生命周期或绑定时机问题。
-
std::stop_callback是 RAII 类型：构造即注册，析构即注销——一旦离开作用域（比如定义在 lambda 内、循环体里、或函数末尾），就立刻失效 - 误用
std::jthread自带的 token：比如写t.get_stop_token()并传给外部std::stop_callback，但该 token 只反映本线程是否被请求停止，无法被外部线程触发回调 - 捕获了悬垂引用：回调里用了局部
std::ofstream或栈上std::mutex的引用，对象已析构却还去访问 - 根本没调
request_stop()，只是设了个自定义 flag ——std::stop_callback只响应std::stop_source::request_stop()
std::stop_callback 必须和 std::stop_source 同生命周期
跨线程取消的前提是：所有线程共享同一个 std::stop_source 实例，且它必须比所有使用它的线程活得更久。
- ❌ 错误：把
std::stop_source声明为局部变量，比如在main()作用域外、或某个函数栈帧内 - ✅ 正确：声明为全局变量、静态变量、或类成员；若在线程启动前构造，需确保其析构晚于所有
std::stop_callback - 每个线程都应通过自己的
source.get_token()获取 token，并各自绑定独立的std::stop_callback实例（不能复用同一 callback 对象） - 构造顺序很重要：先声明
std::stop_source和std::stop_callback，再启动std::jthread；否则可能注册失败
std::stop_callback 里只能做轻量无阻塞操作
它运行在调用 request_stop() 的线程上下文中，不是工作线程自身，因此必须极快返回。
- ✅ 安全操作：
close(fd)（裸 fd）、delete ptr（非托管内存）、done_flag.store(true, std::memory_order_relaxed)、cv.notify_one() - ❌ 禁止操作：
std::ofstream::close()（可能刷盘阻塞）、std::mutex::lock()（可能竞争死锁）、std::this_thread::sleep_for()、等待其他线程结束 - 多个
std::stop_callback绑定到同一 token 时，执行顺序不保证，不能互相依赖 - 回调不重入、不排队、执行完即失效——它不是事件循环，也不是钩子机制
std::jthread 析构时自动 request_stop() 却静默失效
这是最隐蔽的坑：你以为 std::jthread 析构会触发回调，结果什么都没发生。
- 原因：析构前
std::stop_callback已提前销毁（比如定义在 lambda 内、或作用域比线程短） -
std::jthread的get_stop_token()是线程私有的，不能用于跨线程广播；想让多个线程统一响应，必须用外部std::stop_source - lambda 参数类型必须是
std::stop_token（或const std::stop_token&），否则std::jthread注入的是默认构造的空 token，后续stop_requested()永远返回 false - 真正难的不是写回调函数，而是确保它活得到
request_stop()被调用的那一瞬间——多数崩溃和静默失效，都出在“以为注册了就万事大吉”，却忽略了作用域和所有权
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
