std::stop_callback仅在request_stop()调用时执行一次指定函数，不终止任务或中断线程；常见失效原因是其RAII特性导致作用域结束即注销，需确保生命周期覆盖整个停止流程。
std::stop_callback 不会终止任务，也不会中断线程执行 —— 它只在 request_stop() 被调用时，执行一次你指定的函数，前提是它还活着。
为什么注册了 std::stop_callback 却没触发？
最常见原因：对象生命周期太短，RAII 析构即注销。
-
std::stop_callback是 RAII 类型，离开作用域就自动注销回调，后续request_stop()完全无效 - 错误写法：
std::jthread t([](std::stop_token token) { std::stop_callback cb(token, []{ /* cleanup */ }); ... });→cb是局部变量，lambda 返回即销毁 - 正确做法：把
std::stop_callback定义在和线程同生命周期的作用域，例如紧挨着std::jthread变量声明之后，或作为类成员 - 更稳妥替代：多数场景下，直接在任务循环里轮询
token.stop_requested()，比管理回调生命周期更简单、更不易出错
std::stop_callback 适合干啥？不适合干啥？
它真正有价值的地方，是响应“非工作线程”的全局清理需求，而不是塞进主逻辑里做业务中断。
- ✅ 合适场景：关闭共享
std::ofstream、释放全局std::shared_mutex、记录终止日志、通知外部服务下线 - ❌ 不适合场景：在回调里做耗时 I/O（如写磁盘）、等待锁、调用
std::mutex::lock()、或阻塞等待其他线程 —— 这些会卡住整个 stop 流程 - ⚠️ 多个
std::stop_callback绑定到同一个std::stop_token时，标准不保证执行顺序，别让它们互相依赖 - ⚠️ 回调执行不重入、不阻塞、不抛异常，也不改变线程状态；它只是“有人想停了”这个事实的通知入口
和 std::jthread 配合时最容易踩的坑
std::jthread 自带 std::stop_source，但它的 std::stop_token 是线程私有的 —— 外部无法靠它广播信号。
立即学习“C++免费学习笔记（深入）”；
- 误以为
t.get_stop_token()能被其他线程监听并响应 —— 实际上它只反映本线程是否收到request_stop()，不能跨线程传播 - 想让多个线程响应同一取消信号？必须用外部
std::stop_source，再通过get_token()分发给各线程 -
std::jthread析构时会自动request_stop()+join()，但如果std::stop_callback已提前析构，这次request_stop()就不会触发任何回调 - lambda 参数类型必须是
std::stop_token（或const std::stop_token&），否则std::jthread不会注入有效 token，传进去的是默认构造的空 token
替代方案：什么时候该放弃 std::stop_callback？
当你发现要花更多精力管理回调生命周期，而不是专注业务逻辑时，大概率该换思路了。
- 任务本身逻辑简单、清理动作少：直接在循环开头加
if (token.stop_requested()) return;最省心 - 需要“立即响应”长操作：把大块工作拆成小段，每段前检查
token.stop_requested()，比依赖回调更可控 - 涉及系统调用（如
read()、accept()）：这些函数不支持std::stop_token，得改用带超时的poll()或epoll_wait()，并在每次超时后检查 token - 回调里要访问外部状态？确保捕获的
std::stop_token和相关对象（如 shared_ptr）生命周期足够长，别捕获已析构对象的引用
真正难的不是写回调函数，而是让它活得到被调用的那一刻，同时不拖慢主线程节奏、不引入锁竞争、也不依赖未定义行为。
