std::stop_source仅发停止信号，线程需主动检查std::stop_token并清理；推荐用std::jthread自动绑定，避免手动组合的生命周期错配等问题，且必须在自然等待点轮询stop_requested()。
std::stop_source 本身不能直接“优雅终止线程”——它只是发信号的开关；真正响应并退出，必须由线程函数主动检查 std::stop_token 并做清理。用错位置或漏检查，request_stop() 就是无效点击。
std::jthread 构造时自动绑定 stop_source，别手写 std::thread + std::stop_source
手动组合 std::thread 和 std::stop_source 容易出三类问题：stop_token 生命周期错配、析构时不自动 request_stop()、忘记把 token 传进线程函数。而 std::jthread 在构造时就内置一个 std::stop_source，并按规则自动把它的 get_token() 作为第一个参数传入线程函数——这是唯一推荐的起点。
- ✅ 正确姿势：
std::jthread t([](std::stop_token st) { /* 检查 st.stop_requested() */ }); - ❌ 错误姿势：
std::thread t([](std::stop_token st) { ... }, src.get_token());——src可能提前析构，st变成悬空 token - ⚠️ 注意：如果线程函数不接收
std::stop_token参数（哪怕只写了个int），std::jthread就不会注入 token，request_stop()后也完全无感知
轮询 stop_requested() 必须放在自然等待点，不是塞进 while 循环就行
常见错误是写 while (!st.stop_requested()) { /* 纯计算 */ }，结果 CPU 占满、无法响应停止请求，甚至错过析构时的 join() 超时。stop_token 不会中断系统调用（如 read()、mutex::lock()），只能靠你把检查点插在“本就要等”的地方。
- ✅ 推荐位置：
std::this_thread::sleep_for()后、queue.pop()返回前、一次recv()成功后 - ✅ 支持取消的等待函数优先用：
cv.wait_until(lock, timeout, st)、shared_mutex.try_lock_shared_for(timeout, st)—— 它们收到停止请求会立刻返回或抛std::stop_exception - ⚠️ 纯计算循环里必须加让步：
std::this_thread::yield()或sleep_for(1ms)，否则可能饿死其他线程且无法及时响应
request_stop() 后线程没停？先确认是否卡在不可取消的阻塞调用里
request_stop() 是原子设置标志位，毫秒级完成；但线程是否退出、何时退出，全取决于它自己跑到了哪个检查点。如果线程正阻塞在 accept()、pthread_cond_wait() 这类不接受 stop_token 的系统调用里，它就只能等调用返回后才可能检查 token。
立即学习“C++免费学习笔记（深入）”；
- ✅ 解法一：改用可取消的替代方案，比如带超时的
poll()+stop_requested()判断 - ✅ 解法二：用
std::stop_callback注册清理动作，确保即使线程卡住，资源也能被释放（注意：回调执行时机依赖stop_source生命周期） - ⚠️ 高危陷阱：
std::jthread析构时会隐式request_stop()+join()；若线程函数从不检查 token，join()就永远卡住，主线程直接死锁
最常被忽略的一点：token 是协作机制，不是魔法开关。它不杀线程、不中断 IO、不释放内存——所有清理逻辑（关闭文件描述符、释放堆内存、通知下游任务）都得你亲手写在线程函数里，并确保检查点足够靠近真实阻塞位置。
