为什么 std::queue + std::condition_variable 不足以实现可靠背压
因为它们只管“有没有数据”，不管“下游能不能吞”。任务入队时若不检查下游消费能力，队列会无限膨胀，内存耗尽或延迟飙升。真正的背压必须让生产者感知下游水位——比如当缓冲区超限时主动阻塞、丢弃或降级。
- 典型错误现象：
std::queue持续 push 而 consumer 处理变慢，queue.size()从几百涨到百万级，OOM 或 GC 压力突增（即使没 GC，malloc 频繁也会卡住） - 关键区别：背压不是“等消费者空闲”，而是“按消费者当前吞吐反向调节生产节奏”
- 推荐做法：用有界队列（如
moodycamel::ConcurrentQueue的 bounded 构造）+ 生产端显式 check 返回值，而非依赖条件变量盲等
用 boost::asio::thread_pool 搭配有界通道实现可中断背压
原生 std::thread 和 std::async 缺乏任务节流语义，boost::asio::thread_pool 虽不内置背压，但配合自定义通道能快速落地。
- 使用场景：IO 密集型流水线（如日志采集 → 解析 → 转发），要求单个 stage 故障时不拖垮上游
- 核心参数：
moodycamel::ConcurrentQueue<task></task>初始化时传入容量上限（如1024），调用enqueue()返回bool——false表示已满，此时不能重试，得走降级逻辑 - 性能影响：有界队列比无界锁竞争略高，但避免了内存失控带来的全局抖动，实测在 4 核机器上 8KB buffer 下吞吐下降
- 示例片段：
if (!channel.enqueue(task)) {<br> metrics::inc("backpressure_dropped");<br> drop_task_safely(task); // 不可直接 delete，需考虑 ownership
std::execution::sender 在 C++23 中仍无法替代手动背压控制
C++23 的 std::execution 提供了 on、then 等组合子，但 sender/receiver 模型本身不约束缓冲行为。是否背压，完全取决于你用的 scheduler 或 channel 实现。
- 常见误解：以为
schedule_on(thread_pool)自动限流 —— 实际它只是把 task post 进 pool 的 internal queue，该 queue 默认无界 - 兼容性风险：MSVC 2022 17.8+ 对
std::execution支持不全，GCC 13 需开启-fconcepts且部分 sender 组合器未优化，线上慎用 - 务实建议：现阶段用
moodycamel::ConcurrentQueue+boost::asio::thread_pool组合更可控；若用 sender，务必自己 wrap 一层带容量检查的receiver
背压策略选型：阻塞 / 丢弃 / 降级，别只看文档描述
“阻塞生产者”听着最安全，但在网络服务中可能引发级联超时；“丢弃”看似激进，但配合 trace ID 记录后，反而更容易定位瓶颈点。
立即学习“C++免费学习笔记（深入）”；
- 阻塞适用场景：离线批处理，任务允许秒级延迟，且上下游速率相对稳定（如 ETL 流程）
- 丢弃适用场景：实时监控上报，单条丢失不影响整体趋势，但 buffer 满本身是重要告警信号
- 降级容易被忽略的点：降级后的任务不能简单扔掉，要确保所有权转移明确 —— 比如用
std::unique_ptr<task></task>入队，丢弃时必须reset()，否则内存泄漏 - 真正复杂的点在于：不同 stage 的背压策略应解耦。例如解析 stage 可丢弃，但存储 stage 必须阻塞，这需要每个 channel 独立配置容量和策略，不能共用一套全局参数
