不是必须，但绝大多数场景下 std::queue + mutex 是最稳妥的选择；替代方案如 boost::lockfree::queue 或 std::atomic_ref 配合无锁结构开发成本高、易出错。
流水线阶段必须用 std::queue + mutex 保护吗？
不是必须，但绝大多数场景下这是最稳妥的选择。裸用 std::vector 或 std::deque 在多线程间传递数据会引发竞态——比如一个线程正在 push_back，另一个线程同时调用 front 或 pop_front，结果未定义。
真正可替代的方案只有两类：boost::lockfree::queue（需确认内存模型兼容）或 C++20 的 std::atomic_ref 配合自定义无锁结构（开发成本高、易出错）。对 95% 的业务级流水线，std::queue 加 std::mutex 是平衡可读性、正确性和维护性的合理选择。
注意两个常见坑：
- 别在
std::queue上直接套std::shared_mutex——它不支持并发读，只支持“多读单写”，而流水线阶段通常是“一生产者一消费者”，用std::mutex更轻量 - 别把整个队列生命周期锁住；应在每次
push/pop操作前后加锁，且立即释放，否则下游线程会长时间阻塞
如何避免 stage 线程忙等（busy-wait）消耗 CPU？
用 std::condition_variable 配合 std::unique_lock 是标准解法。关键不是“有没有用 cv”，而是“wait 的条件是否精确”。
立即学习“C++免费学习笔记（深入）”；
典型错误是写成：cv.wait(lock, [&]{ return !q.empty(); }); 却没处理虚假唤醒或中断信号。正确做法是：
- 始终在
while循环中检查条件，而非if - 在
notify_one()前确保队列已插入新元素，且操作在同一个锁保护下完成 - 若需支持优雅退出，给每个 stage 添加
std::atomic<bool> shutdown{false}</bool>，并在 wait 条件中加入!shutdown.load()
示例片段：
while (!shutdown.load() && q.empty()) {
cv.wait(lock);
}
if (shutdown.load() && q.empty()) break;
auto item = std::move(q.front());
q.pop();
stage 之间传值该用 move 还是 shared_ptr？
取决于数据大小和所有权语义。小对象（如 int、std::array<float, 8>）直接传值 + std::move 开销最小；大对象（如图像帧、网络包）用 std::shared_ptr 更安全，但要注意引用计数原子操作带来的轻微开销。
容易被忽略的一点：如果某个 stage 可能丢弃数据（例如过滤 stage 不满足条件就跳过），用 std::shared_ptr 能自然管理生命周期；而用值语义时，你得自己确保 move 后原对象处于有效但未定义状态（比如 move 构造后清空 vector）。
实操建议：
- 所有 stage 输入参数统一用
std::shared_ptr<Data>，哪怕 Data 很小——统一接口比微优化更重要 - 若性能压测发现引用计数成瓶颈，再改用 arena 分配器 + raw 指针 + 显式生命周期管理（此时必须引入 stage 间的同步协议）
怎么让 pipeline 支持动态启停某个 stage？
核心是把每个 stage 封装为独立的 std::jthread（C++20）或带 std::atomic<bool></bool> 控制的 std::thread，并暴露 start() / stop() 接口。
难点不在启停本身，而在 stage 之间的缓冲区状态一致性。例如 stage2 停止时，stage1 仍在往它的输入队列 push，必须防止队列无限增长。
解决方案是：每个 stage 内部维护一个 std::atomic<StageState>（Running / Stopping / Stopped），并在 push 前检查下游状态。更健壮的做法是让上游 stage 在 push 失败时缓存数据或触发回调——但这已经超出基础流水线范畴，属于流控策略了。
一句话提醒：动态启停不是“调个函数就行”，它把简单线性依赖变成了带状态机的图状依赖，调试难度陡增。除非真有运行时重配置需求，否则静态构建 pipeline 更可靠。
