std::stop_callback的回调仅在关联std::stop_source调用request_stop()后且自身未析构时执行，不保证立即或同步运行，需确保其生命周期长于stop_source及触发上下文，并避免捕获已销毁资源或抛异常。
std::stop_callback 什么时候真正触发
std::stop_callback 的回调函数只在关联的 std::stop_source 被显式调用 request_stop() 后、且该 callback 尚未被析构时执行。它**不保证在任意线程中立即运行**，也不在 request_stop() 调用瞬间同步执行——实际执行时机取决于 stop token 的持有者是否正在轮询或等待（比如 std::condition_variable::wait_until 带 stop_token 的重载）。如果你在非等待上下文中依赖它做清理，很可能根本没机会运行。
常见错误现象：std::stop_callback 构造后，std::thread 已经退出，但回调从未执行；或者回调执行时资源（如 std::ofstream、裸指针）早已被外层作用域析构。
- 确保 callback 对象生命周期长于其关联的
std::stop_source和所有可能触发停止的上下文 - 不要在栈上临时构造
std::stop_callback并期望它“自动注册”——它必须持有一个活跃的std::stop_token，且自身需保持存活 - 若用于线程函数内部，建议将
std::stop_callback声明为函数作用域内的局部变量（非临时），或绑定到类成员
如何避免回调中访问已销毁资源
最典型的坑是：回调捕获了局部对象的引用或指针，而该对象在 request_stop() 发起前就离开了作用域。例如在线程函数里捕获 std::vector<int>&</int> 或 FILE*，但线程还没结束、主线程已 return。
正确做法是让 std::stop_callback 拥有它需要清理的资源，或至少确保资源生命周期由外部明确管理。
- 优先捕获资源的所有权：用
std::shared_ptr包裹文件句柄、缓冲区等，回调中持有一个std::shared_ptr副本 - 避免捕获 this 指针并调用成员函数，除非你 100% 确保对象存活（例如该对象本身拥有
std::stop_source且不会早于 callback 析构） - 若必须用裸资源（如
int fd），应在 callback 外部统一管理生命周期，callback 只负责逻辑上的“标记关闭”，真实 close() 由持有者在析构时兜底
示例：
auto handle = std::make_shared<int>(open("/tmp/log", O_WRONLY));<br>std::stop_callback cb(token, [handle]( ) { if (*handle >= 0) close(*handle); });</int>
std::stop_callback 和 std::jthread 的配合要点
std::jthread 自动管理 std::stop_source，并在析构时调用 request_stop()，这看似完美，但容易误以为“只要用了 jthread，callback 就一定安全运行”。实际上，std::jthread 的析构是同步的，但它的 stop token 传递和 callback 执行仍是异步时机——如果线程函数已快速退出，callback 可能来不及执行就被销毁。
- 把
std::stop_callback声明在std::jthread的线程函数内，并放在尽可能靠前的位置（比如函数开头），以延长其生命周期 - 不要依赖
jthread.join()来“等待 callback 执行完”——join()只等线程函数返回，不等 callback 执行 - 若需强顺序保障（比如必须 close 文件后再继续），改用主动轮询 +
stop_token.stop_requested()，在函数末尾显式清理，而非全靠 callback
为什么不能在 callback 里 throw 异常
std::stop_callback 的回调函数签名是 void()，且 C++20 明确规定：若其抛出异常，会直接调用 std::terminate()。这不是设计疏漏，而是为了匹配取消语义——停止是协作式、不可逆的信号，不应引入异常传播这种不确定控制流。
- 所有 I/O、内存释放、锁操作都必须是无异常的（noexcept）或自行吞掉异常（如 try/catch + 日志）
- 避免在 callback 中调用可能抛异常的 STL 容器操作（如
std::vector::push_back） - 若清理逻辑复杂，建议封装成独立的 noexcept 函数，再传给
std::stop_callback构造函数
容易被忽略的地方：很多 RAII 类析构函数默认不是 noexcept，直接在 callback 中销毁它们可能意外抛异常。务必检查或显式声明为 noexcept。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
