std::jthread构造时不能直接传std::stop_token，而需传入首个参数为std::stop_token的可调用对象，如[](std::stop_token st){while(!st.stop_requested()){/work/}}。
std::jthread 构造时传 stop_token 怎么写？
不能直接把 std::stop_token 传给 std::jthread 构造函数——它不接受这个参数。真正能控制停止的，是构造时传入的可调用对象是否接收 std::stop_token 参数。
编译器会自动检测函数签名：如果第一个参数类型是 std::stop_token，std::jthread 就会在启动时把内部的 std::stop_source 关联的 token 传进去；否则就当普通函数调用，收不到停止信号。
- ✅ 正确写法：
std::jthread t([](std::stop_token st) { while (!st.stop_requested()) { /* work */ } }); - ❌ 错误写法：
std::jthread t([]{});—— 这个 lambda 没声明接收std::stop_token，后续调用t.request_stop()完全无效 - ⚠️ 注意：参数名不重要，类型和位置才关键；必须是第一个参数，且类型精确匹配
std::stop_token（不能是const std::stop_token&等变体，某些标准库实现会拒绝）
request_stop() 调用后线程不一定立刻退出
std::jthread::request_stop() 只是设置停止状态并唤醒等待中的 stop_condition，它不阻塞、不等待、不中断正在运行的代码。线程是否退出，完全取决于你在线程函数里怎么检查和响应。
- 常见错误：只在循环开头检查
st.stop_requested()，但循环体里有长耗时操作（比如sleep_for、IO、计算），导致实际响应延迟数秒甚至更久 - 推荐做法：在可能阻塞的地方主动轮询或使用带 token 的等待函数，例如：
cv.wait(lock, st, []{ return ready; });或mtx.try_lock_until(st, deadline); - 注意
std::this_thread::yield()和空循环不是可靠响应方式，既浪费 CPU，又不保证及时性
析构时自动 join() 的安全边界在哪？
std::jthread 析构时会调用 join()，这是它比 std::thread 更安全的核心原因。但前提是线程函数必须能「在合理时间内完成」，否则析构会卡死主线程。
立即学习“C++免费学习笔记（深入）”；
- 典型陷阱：线程函数里有无条件的
while(true)且没检查stop_requested()，析构时永远等不到结束 - 更隐蔽的问题：线程持有锁、等待外部事件（如 socket 连接）、或依赖另一个已销毁的资源（比如捕获了局部
std::mutex的引用） - 建议在析构前显式调用
request_stop()，并确保线程函数逻辑上具备终止路径；必要时加超时保护（虽然std::jthread本身不提供try_join_for，但可用std::thread+ 手动管理替代）
和 std::thread 混用 stop_source 会出什么问题？
可以共享 std::stop_source，但要注意生命周期和所有权。多个 std::jthread 共享同一个 std::stop_source 是合法的，但若其中一个 std::jthread 析构后，它的内部 std::stop_source 就失效了，此时再通过它调用 request_stop() 是未定义行为。
- 错误模式：
auto st_src = t.get_stop_source(); t.~jthread(); st_src.request_stop();——t析构后st_src不再有效 - 安全做法：需要跨线程协调停止时，自己创建独立的
std::stop_source，传给多个线程，并确保它存活时间 >= 所有使用者 - 别依赖
std::jthread::get_stop_source()返回的临时对象长期持有；它只是对内部源的拷贝，拷贝后原jthread仍控制其生命周期
停止机制不是“发令即停”的魔法，而是协作式契约：你得在函数里查、在阻塞点让、在析构前留退路。漏掉任一环，std::jthread 就只剩个自动 join() 的壳子。
