std::stop_token 仅是观察者，不能停止线程；真正触发停止的是 std::jthread 析构或 request_stop()，线程函数必须主动轮询 stop_requested() 并配合 stop_callback 打破阻塞。
std::stop_token 本身不能停止线程
std::stop_token 只是一个“观察者”，它不触发停止，也不调用任何终止逻辑。它只提供一种方式让线程**主动轮询**是否被请求停止。真正发起停止的是 std::jthread 的析构或显式调用 request_stop() —— 此时关联的 std::stop_source 状态变为 stop_requested，stop_token::stop_requested() 才会返回 true。
常见错误是以为构造一个 std::stop_token 就能“控制”线程，结果线程照常运行到底。关键在于：线程函数内部必须检查 token，且外部必须有机制（如 std::jthread 自动析构）去触发请求。
- 仅靠
std::stop_token+ 普通std::thread无法实现协作式停止（因为普通std::thread没绑定std::stop_source） -
std::jthread在构造时自动关联一个std::stop_source，其get_stop_token()返回的 token 才有意义 - 线程函数若未检查 token，即使外部调用了
request_stop()，该线程也不会响应
用 std::jthread + stop_token 实现同步等待终止
最典型的同步场景是：主线程希望“等线程做完当前任务后干净退出”。这需要线程函数在循环中定期检查 stop_token::stop_requested()，并在为 true 时跳出循环、完成清理、自然返回。
示例结构如下：
立即学习“C++免费学习笔记（深入）”；
std::jthread worker([](std::stop_token stoken) {
while (!stoken.stop_requested()) {
// 执行一段工作（比如处理一个队列项）
if (auto item = queue.pop(); item.has_value()) {
process(*item);
} else {
std::this_thread::sleep_for(10ms); // 避免忙等
}
}
// 这里可做退出前清理（如 flush 日志、释放资源）
});
- lambda 参数
std::stop_token由std::jthread自动传入，与内部stop_source绑定 - 必须在循环条件或关键检查点调用
stoken.stop_requested()，不能只在开头查一次 -
std::jthread析构时自动调用request_stop()并join()，所以无需手动管理生命周期 - 若需提前终止，直接调用
worker.request_stop()，随后它会在下次轮询时退出
stop_callback 能帮你避免轮询但不解决同步阻塞
如果线程卡在某个不可中断的系统调用（如 read()、accept() 或无超时的 std::condition_variable::wait()），单纯轮询 stop_requested() 无效——它根本没机会检查。
此时可用 std::stop_callback 注册一个回调，在 request_stop() 被调用时**异步触发**，例如关闭 socket、通知条件变量：
std::jthread server([](std::stop_token stoken) {
int sock = socket(...);
std::stop_callback cb(stoken, [sock] { close(sock); }); // 请求停止时立即关 socket
while (!stoken.stop_requested()) {
struct sockaddr_in addr;
socklen_t len = sizeof(addr);
int client = accept(sock, (struct sockaddr*)&addr, &len); // 可能阻塞
if (client == -1 && errno == EINTR) continue; // 被信号中断，重试
if (client > 0) handle_client(client);
}
});
-
std::stop_callback构造即注册，析构自动注销；它不阻塞，只是“发个通知” - 它不能替代轮询，而是配合使用：回调负责打破阻塞，轮询负责决定何时彻底退出
- 注意回调中不要做耗时或可能抛异常的操作（标准要求回调必须是
noexcept）
别忽略 stop_token 的拷贝语义和空状态
std::stop_token 是可拷贝、可移动的轻量对象，但它的“有效性”依赖于原始 std::stop_source 是否还存在。一旦 std::jthread 析构，其内部 stop_source 销毁，所有从它派生的 token 都变成“空状态”（stop_possible() == false，stop_requested() == false）。
- 不要把
stop_token存到全局或长期持有的容器里，除非你确保jthread生命周期足够长 - 在 lambda 外部捕获
stoken时，注意它只是副本，不影响源 token 的生命周期 - 调试时可用
stoken.stop_possible()判断 token 是否仍有效（比如用于断言或日志） - 某些平台（如 MSVC 早期 C++20 实现）对
stop_callback支持不完整，建议编译时加/std:c++20并确认 STL 版本
真正容易被忽略的，是“线程函数必须自己决定在哪停、怎么停”——std::stop_token 只递话，不干活。协作式终止的健壮性，最终取决于你在线程逻辑中插入检查点的位置和时机。
