线程池不该用std::future包裹任务，因其引入额外内存分配、锁竞争和隐式拷贝风险，导致吞吐降低30%～50%；应改用std::function入队并由调用方自行管理结果或回调。
线程池该不该用 std::future 包裹任务
不该。std::future 是为单次、异步、结果驱动的调用设计的，而线程池的核心诉求是复用线程 + 高吞吐任务调度。强行用 std::promise/std::future 包每项任务，会带来三重开销：额外内存分配（每个 promise 对象）、锁竞争加剧（promise 构造/设置需同步）、以及 move 语义穿透带来的隐式拷贝风险（尤其捕获 lambda 时）。实际压测中，带 std::future 的任务提交吞吐常比裸函数对象低 30%～50%。
更合理的方式是：任务入队用 std::function<void></void>，需要返回值时由调用方自行管理上下文（比如传入一个 std::shared_ptr 结果容器），或统一用回调函数（std::function<void></void>）代替 future。
任务队列用 std::queue 还是 std::deque
选 std::deque。虽然 std::queue 默认底层也是 std::deque，但显式用 std::deque 更利于控制行为：
-
std::queue封装过严，无法直接调用shrink_to_fit()或迭代器遍历，调试时查队列长度、dump 未执行任务都困难 - 多线程下
std::deque::push_back()和pop_front()的平均复杂度是分摊 O(1)，且内存局部性优于std::vector；而std::queue不暴露这些接口，你没法在空闲时主动释放多余缓冲区 - 某些 STL 实现中，
std::queue对empty()的调用可能隐含锁或原子操作（尤其 debug build），而直接操作std::deque可确保只在你加锁的临界区内访问
如何安全终止线程池中的 worker 线程
不能靠 std::thread::join() 直接阻塞等待——worker 正在执行 long-run 任务时，join 会卡死。必须用「协作式中断」+「任务队列清空信号」双机制：
- 维护一个
std::atomic<bool> stop_requested{false}</bool>，所有 worker 循环开头检查它 - 停止前先置
stop_requested = true，再向任务队列 push 一个特殊哨兵任务（如空std::function<void></void>），确保至少有一个 worker 能被唤醒 - worker 拿到任务后，先判是否为空；是则立即退出循环，否则执行
- 主线程调用
join()前，要确保所有 worker 已退出循环，且队列已空（可加一个简单的 while-loop 等待workers_.size() == 0）
漏掉哨兵任务或忽略空任务判断，会导致部分线程永远阻塞在 cv_.wait() 上，无法 join。
为什么不要在 worker 线程里捕获 std::exception_ptr
因为 std::exception_ptr 本身不携带栈信息，且在线程间传递需显式 rethrow —— 一旦 worker 捕获异常后仅存 std::current_exception() 而不处理，主线程根本无从得知发生了什么。更糟的是，若多个 worker 同时抛异常，std::exception_ptr 会丢失原始发生位置。
务实做法是：任务函数内部自行处理异常（记录日志、调用错误回调），或约定任务签名统一为 std::function<void></void>，把错误归一化为 std::error_code 传回。这样既避免异常跨线程传播的不确定性，也方便上层做分类重试或熔断。
真正难的不是写出让线程跑起来的代码，而是让它们在出错时不静默、在停止时不卡死、在高负载时不互相拖慢——这些细节藏在 stop_requested 的读序、cv_.notify_one() 的调用时机、和任务对象移动构造的 const 正确性里。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
