std::stop_token必须由std::jthread自动传入线程函数首个参数，不可默认构造或捕获；应优先用stop_requested()轮询而非stop_callback；request_stop()仅设标志，需线程主动配合检查。
std::stop_token 怎么拿到并传给线程函数？
你不能凭空构造 std::stop_token，它必须从 std::jthread 的 get_stop_token() 拿，或从另一个 std::stop_source 获取。直接在线程函数里声明 std::stop_token 参数但不传入，会导致编译失败或默认构造出“无效 token”（stop_possible() == false）。
正确做法是：用 std::jthread 启动线程，它会自动绑定一个 std::stop_source，并在启动时把对应的 std::stop_token 作为第一个参数传入线程函数。
-
std::jthread是唯一能自动提供有效std::stop_token的标准线程类型；std::thread不支持协作取消 - 线程函数签名必须以
std::stop_token为首个参数，否则std::jthread不会自动注入 - 如果函数是 lambda，捕获
std::stop_token无效——必须作为形参显式接收
void worker(std::stop_token st) {
while (!st.stop_requested()) {
// 做事...
std::this_thread::sleep_for(100ms);
}
}
std::jthread t{worker}; // ✅ 自动传入有效 token
stop_requested() 和 stop_callback 该选哪个轮询方式？
绝大多数场景下，只用 stop_requested() 就够了。它轻量、无副作用、可频繁调用。而 std::stop_callback 是“注册一次、触发一次”的机制，适合清理资源，不适合轮询。
-
stop_requested()返回bool，线程内可随时检查，适合循环条件或早期退出分支 -
std::stop_callback构造时绑定一个 callable，仅在停止请求发出且 token 有效时执行一次；若线程已退出或 token 失效，回调不会运行 - 误用
stop_callback替代轮询会导致：停止请求被忽略（因为回调只触发一次，而线程可能还在循环中） - 回调对象的生命周期必须长于
std::stop_callback实例，否则析构时可能访问悬垂引用
// ❌ 错误：以为回调能反复通知
std::stop_callback cb{st, []{ cleanup(); }}; // 只执行一次
// ✅ 正确：用 stop_requested() 控制循环
while (!st.stop_requested()) {
do_work();
}
cleanup(); // 循环退出后再清理
std::jthread::request_stop() 为什么有时没反应？
常见原因是线程函数没在检查 stop_requested()，或者检查频率太低（比如阻塞在 std::condition_variable::wait() 中）。C++20 协作取消完全依赖线程主动配合，没有强制中断能力。
立即学习“C++免费学习笔记（深入）”；
-
std::jthread::request_stop()只是设置标志位，不挂起、不抢占、不抛异常 - 如果线程卡在系统调用（如
read()、sleep()）或无检查的长循环里，停止请求会一直等待 -
std::condition_variable::wait()有重载支持std::stop_token，应优先使用：cv.wait(lock, st, predicate) - 对
std::this_thread::sleep_for()这类不可中断操作，需手动拆成带检查的小间隔循环
// ✅ 支持中断的等待
cv.wait(lock, st, []{ return ready; });
// ✅ 手动分段 sleep（避免长时间阻塞）
for (int i = 0; i < 10 && !st.stop_requested(); ++i) {
std::this_thread::sleep_for(100ms);
}
和 std::thread + flag bool 相比，std::stop_token 有什么实际区别？
核心区别不是“能不能停”，而是“谁负责同步、是否线程安全、能否组合”。裸 flag 需要自己加 std::atomic 和内存序，而 std::stop_token 把这些封装好了，还支持嵌套取消源（比如子任务继承父任务的 token）。
- 裸
std::atomic<bool></bool>只能表达“单层开关”，无法区分“请求停止”和“已停止”，也难以安全传递给多个子线程 -
std::stop_token与std::stop_source绑定，天然支持“一个 source 控制多个 token”，适合树状任务结构 -
std::stop_token::stop_requested()内部已做最优内存序（通常是memory_order_acquire），不用手写 - 调试时，
stop_token可通过stop_possible()判断是否还有效，裸 flag 无法反映“token 是否已被 move 或销毁”
真正容易被忽略的是：一旦 std::jthread 对象析构，其绑定的 std::stop_source 会自动 request_stop —— 这是隐式行为，若线程函数没响应，就会变成“静默未终止”。
