分支逻辑控制下的循环缓冲区本质是外围逻辑依据数据特征动态选择处理路径，Ring Buffer仅原子承载字节流；需2的幂容量、位运算索引、独立缓存行对齐、POD类型约束及P99延迟验证。
分支逻辑控制下的循环缓冲区，本质不是给 Ring Buffer 加 if-else，而是指在读写路径中，依据数据类型、优先级或生命周期状态，动态选择不同的处理分支——比如跳过校验、直通转发、拆包重组或丢弃。这种控制必须嵌入在无锁前提下，否则就失去高吞吐意义。核心在于：环形结构本身不参与分支决策，分支由外围逻辑驱动，而 Ring Buffer 只负责原子、确定性地承载字节流。
用位运算+预留空槽实现零锁读写判据
容量必须是 2 的幂（如 1024、4096），才能用 tail_ & (CAPACITY - 1) 替代取模，避免除法开销。判空与判满不能共用 head == tail 这一条件，否则无法区分：
- 判空：head_.load(std::memory_order_acquire) == tail_.load(std::memory_order_acquire)
- 判满：(tail_.load(std::memory_order_acquire) + 1) & (CAPACITY - 1) == head_.load(std::memory_order_acquire)
- 每次更新 tail_（写入后）必须用 std::memory_order_release；读取前 head_ 也需 acquire，确保内存可见性
分支逻辑不侵入 RingBuffer 内部，只作用于读写前后
RingBuffer<uint8_t> 本身只存原始字节，不感知语义。分支控制放在消费者/生产者线程中：
- 生产者侧：根据消息 type 字段决定是否压缩、是否加时间戳、是否写入辅助 ring（如 metadata ring）
- 消费者侧：读出后先解析 header（如前 4 字节为 type），再跳转到对应 handler（fast path / slow path / drop path）
- 关键点：所有分支跳转必须在 ring 外完成，ring 内仅做 memcpy 或原子拷贝，不执行虚函数调用、异常抛出或锁操作
规避 false sharing 与非 POD 类型陷阱
两个原子索引 head_ 和 tail_ 必须各自独占缓存行（64 字节），否则读写竞争会引发总线广播风暴：
- 定义时用 alignas(64)：alignas(64) std::atomic_size_t head_{0}; alignas(64) std::atomic_size_t tail_{0};
- 禁止直接存 std::string、std::vector 等 non-POD 类型；若需复杂结构，用 placement new + 显式析构，或改用 RingBuffer<std::unique_ptr<Msg>>（但注意堆分配延迟）
- 推荐方案：固定布局结构体 + union 分支字段，例如 struct Packet { uint8_t type; uint16_t len; uint8_t payload[256]; }，type 决定 payload 解析方式
多线程吞吐验证的关键指标不是“不崩溃”，而是延迟分布
真实高吞吐场景下，P99 延迟比平均值更重要。测试时应：
- 用 perf record -e cycles,instructions,cache-misses 监控 CPU 流水线效率
- 观察 L1d cache miss ratio 是否低于 2%，过高说明访问不局部
- 用 ftrace 或 eBPF 跟踪 atomic_load/store 的实际指令周期，确认未退化为锁总线操作
- 对比 1 生产者 1 消费者 vs. 4 生产者 4 消费者下，P99 延迟增幅是否小于 1.5 倍（理想无锁应接近线性）
