std::jthread析构时仅自动join()，不自动request_stop()；必须显式调用request_stop()再让对象析构，才能实现“请求停止+等待汇合”，否则join()将无限阻塞。
std::jthread 析构时不会自动 request_stop()，只自动 join()；想“自动停止+自动汇合”，必须手动调用 request_stop()，再让对象离开作用域。
析构只做 join，不发 stop 信号
这是最常被误解的一点：jthread 的析构函数只会检查线程是否仍在运行，若为 joinable 状态，则无条件调用 join() —— 它完全不管线程函数里有没有响应退出逻辑。即使你没传 std::stop_token，也没调过 request_stop()，它照样等你“做完所有事”才返回。
- 不传
std::stop_token的线程函数，request_stop()调用成功但静默失效 - 线程函数里没检查
st.stop_requested()，request_stop()就等于没按开关 - 如果线程卡在死循环或阻塞 I/O（如
read()、无超时的condition_variable::wait()），join()会永远阻塞
request_stop() 必须在析构前显式调用
想让线程真正“提前退出”，只能靠你自己控制时机：在确定要结束线程时，主动调用 request_stop()，然后让 jthread 对象自然析构触发 join()。这不是两个动作的“绑定”，而是你必须写的两步。
- 正确顺序：
t.request_stop();→ 等待线程响应 →t离开作用域（或被 move 赋值为jthread{}） - 不能反过来：先让
t析构，再试图调request_stop()—— 会抛std::system_error（errc::operation_not_permitted） - 可以在任意线程调用
request_stop()，它是线程安全的，但不等待也不保证线程已停
带 stop_token 的线程函数怎么写才不卡住
光有 request_stop() 不够，线程内部必须高频、及时响应，并避免空转或无限阻塞。
- 必须把
std::stop_token作为线程函数的**首个参数**，否则构造时无法绑定内部stop_source - 不要写
while (!st.stop_requested()) { /* work */ }这种 tight loop，CPU 占满且无法响应中断 - 推荐组合：
st.stop_requested()+std::this_thread::sleep_for()或带超时的cv.wait_until(..., st) - 阻塞系统调用（如 socket
recv()）需配合st检查 + 可中断句柄（如io_uring）或超时重试，stop_token本身不中断系统调用
异常场景下 request_stop() 和 join() 的执行顺序很关键
如果你在线程函数里抛了异常，而没捕获，jthread 析构时仍会 join()，但线程可能已经终止——此时 join() 是安全的，但资源清理可能漏掉。
- 线程函数应包裹
try/catch，确保异常路径也能执行清理逻辑（如关闭文件、释放内存） - 用
std::stop_callback注册的回调，在request_stop()后立即执行，适合做轻量级、无异常的收尾（如置标志位、唤醒等待者） -
std::jthread不是万能兜底：它解决的是“忘记 join 导致崩溃”，不是“线程逻辑写错导致卡死”
真正容易被忽略的是：自动 join 只负责“等”，不负责“停”；协作式退出的有效性，100% 取决于你在线程函数里是否写了响应逻辑、是否加了合理等待、是否覆盖了所有退出路径。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
