std::stop_callback不能直接捕获线程终止信号，因为它仅响应std::jthread的request_stop()或显式stop_source::request_stop()，不处理系统信号；普通std::thread无关联stop_source，故无法触发。
std::stop_callback 为什么不能直接捕获线程终止信号
std::stop_callback 不是中断钩子，也不监听系统信号（如 SIGTERM），它只响应 std::jthread 的 request_stop() 或手动调用 stop_source::request_stop()。如果你在普通 std::thread 里构造 std::stop_callback，它根本不会触发——因为普通线程没有关联的 std::stop_source。
必须搭配 std::jthread 或显式管理 std::stop_source 才能生效。常见错误是把 std::stop_callback 当作全局退出监听器，结果回调从不执行。
- ✅ 正确：在
std::jthread启动函数内部构造std::stop_callback，绑定当前线程的stop_token - ❌ 错误：在主线程构造
std::stop_callback并传入子线程的stop_token，但没确保该 token 仍有效（比如子线程已退出） - ⚠️ 注意：
std::stop_callback对象生命周期必须 stop_token 生命周期；否则析构时可能触发未定义行为
如何在 jthread 中注册 stop_callback 并保证安全析构
最简可行模式是在 std::jthread 的可调用对象内，用其 stop_token 构造 std::stop_callback，并让回调持有需要清理的资源（如文件句柄、内存指针）。关键点在于：回调函数本身不能抛异常，且不能依赖外部状态是否还存活。
std::jthread t([](std::stop_token st) {
std::vector<int> buf(1024);
// 注册回调：buf 在线程被请求停止时自动释放
std::stop_callback cb(st, [&buf]() {
buf.clear(); // 安全：buf 在此作用域内有效
printf("cleanup done\n");
});
while (!st.stop_requested()) {
std::this_thread::sleep_for(100ms);
}
});
-
std::stop_callback构造即注册，析构即注销；不需要手动管理注册/注销逻辑 - 若线程运行中
st.stop_requested()已为 true，回调会**立即同步执行**（在std::stop_callback构造时），所以要避免在回调里做重操作 - 不要在回调中调用
st.request_stop()—— 可能引发递归或死锁
stop_callback 和 stop_source 分离使用的边界场景
当多个线程需响应同一停止信号（例如服务级 shutdown），应共享一个 std::stop_source，而非每个线程各自 request_stop()。这时 std::stop_callback 要绑定来自同一 stop_source 的 stop_token。
立即学习“C++免费学习笔记（深入）”；
典型错误是误以为 stop_source 可跨线程拷贝后独立使用——实际上拷贝的是引用语义，所有副本控制同一停止状态；但若原 stop_source 被销毁，其余副本的 stop_token 会变成无效（stop_possible() == false），导致 std::stop_callback 构造失败或静默失效。
- ✅ 推荐：将
std::stop_source作为类成员或全局资源持有，通过get_token()分发stop_token - ❌ 避免：
std::stop_source{}临时构造后立刻传给其他线程——该对象可能在其他线程还没构造完std::stop_callback就已析构 - 调试技巧：检查
token.stop_possible()返回值，确认 token 是否仍有效
为什么 stop_callback 不触发？几个隐蔽原因
最常见的“不触发”不是 bug，而是逻辑误判。比如线程已自然退出，std::jthread 析构时自动调用 request_stop()，但此时 std::stop_callback 对象早已随栈帧销毁，回调没机会执行。
- 线程函数返回前未等待
stop_requested()，导致std::jthread析构时才触发，但回调对象已不在作用域 -
std::stop_callback持有std::shared_ptr等智能指针，而回调执行时对应对象已被释放（循环引用或提前 reset） - 在回调中调用了阻塞 I/O（如
std::cin >> x），导致整个停止流程卡住 ——std::stop_callback是同步执行的，不能耗时 - 编译器优化干扰：某些旧版 libstdc++ 在 -O2 下可能跳过 stop_token 检查，建议用较新 GCC / Clang + 标准库
真正难调试的是回调执行了但效果不可见——比如清空了某容器，但你检查的是另一个副本；或者日志输出被缓冲未刷出。别急着怀疑 std::stop_callback，先确认它是否真的进了回调体。
