根本原因是std::queue未加锁导致竞态，且主线程退出时未join()线程致析构调用std::terminate()；须用std::mutex保护push/pop，std::condition_variable避免轮询，并确保每个std::thread析构前已join()。
std::thread + std::queue 实现任务队列时，为什么任务总不执行？
根本原因通常是 std::queue 未加锁，或生产者/消费者线程对共享队列的访问存在竞态。更隐蔽的问题是：主线程退出前没等待工作者线程结束，导致 std::thread 对象析构时调用 std::terminate()。
- 必须用
std::mutex保护std::queue的push()和pop()；仅声明std::queue为std::atomic无效（它不支持原子操作） - 使用
std::condition_variable替代轮询——避免空转消耗 CPU，且能精确唤醒等待线程 - 每个
std::thread对象在析构前必须处于joinable()状态，推荐在析构函数中统一调用join()，不要用detach() - 任务函数对象需支持移动语义：用
std::function<void> &&</void>接收，再通过std::move()存入队列，否则可能触发拷贝失败（如捕获了不可拷贝的 lambda）
std::packaged_task 和 std::future 怎么配合线程池返回结果？
直接把 std::future 塞进队列不行——它不可拷贝、不可默认构造，且一旦被 get() 过就失效。正确做法是让线程池只负责执行，结果由 std::packaged_task 自动绑定到其关联的 std::future 上。
- 定义任务类型为
std::packaged_task<void></void>（无参无返回），或泛型封装如std::packaged_task<r></r> - 创建任务时：先构造
std::promise<r></r>，再用std::bind或 lambda 包装原始函数 + promise.set_value()，但更简洁的是直接用std::packaged_task构造器接收可调用对象 - 入队前调用
task.get_future()获取对应std::future并返回给调用方；工作者线程执行task()后，future 自动就绪 - 注意：
std::future::get()是阻塞的，若想非阻塞检查，用wait_for(std::chrono::seconds(0)) == std::future_status::ready
线程池 shutdown 逻辑为何不能只靠 flag + condition_variable？
仅设置一个 bool stop_requested 并通知条件变量，会导致正在执行的任务被强行中断（C++ 标准线程不支持抢占式取消），且已入队但未取走的任务永久丢失。
- shutdown 应分两阶段：先设 flag 禁止新任务入队（
enqueue()返回 false 或抛异常），再等待队列清空 + 所有活跃任务完成 - 工作者线程循环中需同时检查两个条件：
!stop_requested || !queue.empty()，否则可能在 flag 为 true 但队列非空时提前退出 - 推荐用
std::atomic<bool></bool>替代普通bool控制 flag，避免编译器优化导致读写重排 - 等待所有线程结束前，要先调用
cv.notify_all()确保阻塞中的线程有机会检查 flag 并退出循环
std::jthread（C++20）能简化哪些老式线程池代码？
std::jthread 内置自动 join() 和协作式中断机制，能直接替代手写的生命周期管理与停止令牌逻辑，但要注意它不是“万能补丁”。
立即学习“C++免费学习笔记（深入）”；
- 构造
std::jthread时传入带std::stop_token参数的函数，工作者线程可通过token.stop_requested()检查是否应退出 -
std::jthread析构时自动调用join()，无需手动写for (auto& t : threads) t.join(); - 但队列本身仍需互斥保护，
std::stop_token不提供同步原语，不能替代std::mutex或std::condition_variable - 若需兼容 C++17，别硬套
std::jthread；可用std::unique_ptr<:thread></:thread>+ RAII 封装模拟类似行为
真正难的不是把任务塞进队列，而是确保每个任务的生命周期边界清晰：从构造、入队、出队、执行、到结果传递，任一环节出现移动语义误用、异常未捕获、或资源未释放，都会导致静默崩溃或内存泄漏。尤其注意 lambda 捕获方式（[=] 可能延长局部对象生命，[&] 在异步场景下极易悬垂）。
