应使用 std::atomic 而非普通 bool 作线程退出标志，因其保证可见性与原子性；需用 store/load（relaxed 序），避免值捕获、确保生命周期，并配合超时等待与 RAII 安全 join。
用 std::atomic<bool></bool> 做线程退出标志，别用普通 bool
普通 bool 在多线程间读写不保证可见性和原子性，编译器可能优化掉轮询、CPU 可能缓存旧值，导致线程永远不退出。std::atomic<bool></bool> 强制内存顺序和原子读写，是最轻量也最可靠的协作式退出机制。
- 必须用
.store(true, std::memory_order_relaxed)修改，用.load(std::memory_order_relaxed)读取（除非你真需要同步其他内存操作） - 不要对
std::atomic<bool></bool>取地址传给线程函数——它不可拷贝，传引用或指针时确保生命周期长于线程 - 常见错误：在 lambda 捕获中按值捕获
std::atomic<bool></bool>，结果每个线程拿到的是副本，改了也没用
线程函数里别死等，要带超时或条件检查
光靠轮询 running.load() 不够优雅，尤其任务本身有阻塞调用（比如 std::this_thread::sleep_for、queue.pop()、网络 recv()）时，可能卡住几十秒才响应退出。
- 把大块阻塞操作拆成带超时的版本：用
std::condition_variable::wait_for替代wait，用std::queue配合互斥锁 + 条件变量，而不是无锁轮询 - 如果用
std::this_thread::sleep_for做周期性检查，睡眠时间别设太长（比如 100ms 而非 5s），否则退出延迟明显 - 某些系统调用（如 Linux 的
epoll_wait）支持被信号中断，但 C++ 标准库线程不处理信号——别指望SIGTERM能直接打断std::thread
std::thread::join() 前必须确保线程已收到退出信号并自然结束
直接调 join() 而不先通知退出，线程还在跑，join() 就会永久阻塞，程序卡死。这不是异常，是逻辑错误。
- 典型流程：设置
running.store(false)→ 等待线程内部检测到并退出 → 再调join() - 别在析构函数里无条件
join()，万一线程还没启动或已 detach，会抛std::system_error（错误信息：resource_deadlock_would_occur或no_such_process） - 更安全的做法：用 RAII 封装，例如自定义
scoped_thread类，在构造时接管std::thread，析构前自动 signal + join，但前提是 signal 逻辑已内聚在线程函数里
别混淆 std::atomic_flag 和 std::atomic<bool></bool>
std::atomic_flag 是 lock-free 的纯标志位，只支持 test_and_set() 和 clear()，没有 load()/store()，也不支持直接赋值。它比 std::atomic<bool></bool> 更底层，但用起来反而更麻烦。
立即学习“C++免费学习笔记（深入）”；
- 除非你在写无锁数据结构且极度抠性能，否则别碰
std::atomic_flag；日常退出控制，std::atomic<bool></bool>语义清晰、可读性强、编译器优化友好 - 错误用法示例：
flag.test_and_set()返回 true 表示“已被设为 true”，不是“当前是 true”——容易逻辑翻转 -
std::atomic<bool></bool>初始化默认是false，而std::atomic_flag默认是true（未清空状态），这个差异常被忽略
