std::stop_callback 是用于在线程收到停止请求后、实际退出前执行一次性清理动作的机制，典型场景是配合 std::jthread 和 std::stop_token 管理文件句柄、锁或监听器等资源，需确保回调对象生命周期长于 stop_callback 实例且避免依赖执行顺序。
std::stop_callback 是什么，它在什么场景下才真正有用
它不是用来“停止线程”的，而是在线程收到 std::stop_token 停止请求后、实际退出前，执行一次性的清理动作。典型场景是：你用 std::jthread 启动了一个工作循环，循环里不断检查 token.stop_requested()，但中间持有文件句柄、锁、或需要注销监听器——这些不能等线程函数返回后再做，得在“确认要停”但“还没退出”的窗口期执行。
必须配合 std::jthread 和 stop_token 才能触发回调
单独构造 std::stop_callback 不会自动生效；它依赖绑定的 std::stop_token 被置为“已请求停止”状态，而这个状态通常由 std::jthread 的析构或显式调用 request_stop() 触发。常见错误是把 std::stop_callback 绑定到一个始终未被请求停止的 token 上，结果回调永远不执行。
-
std::jthread析构时自动调用request_stop()，这是最常用且安全的触发方式 - 手动调用
th.request_stop()也能触发，但需确保线程还在运行（否则可能无效果） - 不要对
std::thread使用 —— 它没有内置 stop_source，无法提供有效 token
回调对象生命周期必须严格长于 stop_callback 实例
std::stop_callback 内部只保存对回调对象的引用（或拷贝），如果回调是个临时 lambda 或栈上对象，而 std::stop_callback 活得比它久，就会触发未定义行为——最常见表现是程序崩溃或静默跳过回调。
正确写法示例：
立即学习“C++免费学习笔记（深入）”；
std::jthread th{[&] (std::stop_token token) {
// 注意：callback 必须在 token 生效期间存活
auto cleanup = std::make_shared<std::string>("cleanup resource");
std::stop_callback cb{token, [&] {
// 这里可以安全使用 *cleanup
printf("releasing %s\n", cleanup->c_str());
}};
while (!token.stop_requested()) {
std::this_thread::sleep_for(10ms);
}
}};
关键点：std::stop_callback 对象本身（cb）必须在作用域内持续存在，直到线程真正退出；它的析构会自动注销回调，所以不能提前销毁。
多个 stop_callback 的执行顺序不可靠，别依赖先后
同一个 std::stop_token 可以注册多个 std::stop_callback，但标准不保证它们的执行顺序。如果你有两个回调分别负责“关闭 socket”和“释放内存”，而后者依赖前者已关闭句柄，那就得自己串行化——比如合并成一个回调，或用互斥量协调。
更稳妥的做法是：每个 std::stop_callback 只做单一、无依赖的资源释放；复杂逻辑收拢到一个回调里，避免竞态和顺序假设。
真正容易被忽略的是：回调执行时，线程可能仍在运行（比如刚退出循环但还没返回），也可能已被系统调度暂停——所以回调里别做耗时操作，也别再调用 token.stop_requested() 判断状态，那已经没意义了。
