线程必须协作退出，不能强制终止；std::thread无stop()因强制中断会导致资源泄漏、锁未释放等未定义行为；应使用std::atomic<bool>作为退出标志，并在阻塞点注入检查。
不能直接“停止”，只能协作退出——线程函数自己返回，才是唯一安全的方式。
为什么 std::thread 没有 stop() 或 kill()
C++ 标准明确禁止提供强制终止接口，因为 std::thread 本身只是 OS 线程的句柄，而强行中断会导致：std::terminate、资源泄漏、锁未释放、析构函数跳过、内存不一致。POSIX 和 Win32 底层也无安全异步终止原语。所有“杀线程”尝试（如 pthread_cancel 或 Windows 的 TerminateThread）都属于未定义行为。
用 std::atomic 做退出标志，但必须正确使用
声明和读写必须严格匹配原子性与内存序：
- 必须声明为
std::atomic<bool> stop_requested{false}</bool>，不能是普通bool或volatile bool - 线程内检查必须每次循环都调用
stop_requested.load()，推荐写成while (!stop_requested.load()) { ... } - 主线程设置时用
stop_requested.store(true)，避免编译器/CPU 重排导致线程永远看不到变化 - 不要只在循环开头检查一次，更不要用
while (true) { if (stop_requested) break; ... }—— 阻塞期间会漏检
线程阻塞在 wait/sleep/I/O 时怎么及时响应
轮询 stop_requested 会浪费 CPU；必须把退出信号“注入”到阻塞点：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 对
std::condition_variable::wait，用带谓词的重载：cv.wait(lock, [&]{ return stop_requested.load() || has_data; }); - 对
std::this_thread::sleep_for，拆成短周期等待：for (int i = 0; i - 对 socket I/O，Linux 下设
SO_RCVTIMEO并配合poll()；Windows 下可用WSAEventSelect+WaitForMultipleObjects - 任何阻塞调用前，都应先检查
stop_requested.load()，并确保唤醒后第一件事仍是检查它
别忘了 join() 和 RAII 清理
设完 stop_requested.store(true) 只是发信号，不是结束：
- 必须调用
t.join()等待线程函数真正返回，否则std::thread对象析构时若仍joinable()，会直接触发std::terminate - 所有资源必须靠 RAII 自动管理：文件用
std::fstream，内存用std::unique_ptr，锁用std::unique_lock（不能用std::lock_guard，因需提前释放） - 自定义资源（如设备句柄）的析构函数必须是
noexcept，且关闭操作不能阻塞（close(fd)在某些场景下可能卡死）
最易被忽略的是：阻塞点唤醒后的条件检查，和析构前是否 join()。这两个地方出错，一个导致线程挂起无法退出，一个导致整个进程崩溃——它们不报编译错误，也不总在测试中暴露。
