环形缓冲区核心是数组加模运算控制游标，非链表；推荐2的幂容量以支持位运算优化，SPSC场景可用内存序替代原子锁，std::span提供零拷贝读写接口。
环形缓冲区的核心是模运算，不是链表
环形缓冲区本质是用数组 + 两个游标（读位置、写位置）模拟首尾相接的结构，std::vector 或裸 char* 都能做，但必须靠模运算控制索引——不是靠指针跳转或链表连接。很多人一上来就写 std::list 或动态分配节点，结果缓存不友好、分配开销大、还失去随机访问能力。
常见错误现象：segmentation fault 出现在多线程写入后读取，其实是没保护好游标更新顺序；或者用 % size 但 size 不是 2 的幂，导致编译器无法优化成位运算，性能掉一截。
- 推荐用
size_t存储容量，并确保它是 2 的幂（如 1024、4096），这样index & (size - 1)可替代index % size - 读写游标建议用
std::atomic<size_t></size_t>（单生产者单消费者场景下可省锁），但注意fetch_add返回的是旧值，别直接当有效索引用 - 不要在构造时就 new 一大块内存——用
std::vector<char></char>管理生命周期更安全，且支持 move
SPSC 场景下避免原子操作的典型写法
单生产者单消费者（SPSC）是最常见也最容易优化的场景。此时读写线程严格分离，只要保证游标更新和数据写入的内存序，就能去掉锁甚至部分原子操作。
使用场景：日志采集线程往缓冲区填数据，主线程定时刷出；或网络收包线程写、解析线程读。
立即学习“C++免费学习笔记（深入）”；
- 写端先用
__atomic_load_n(&write_pos, __ATOMIC_RELAX)拿当前写位置（GCC/Clang），再计算剩余空间，填完数据后才用__atomic_store_n(&write_pos, new_pos, __ATOMIC_RELEASE) - 读端对称：先
load读位置，再读数据，最后store新读位置——中间不能被编译器重排 - 切忌把整个“判断+写入”包进一个
fetch_add：它只保原子性，不保数据已落内存，容易读到脏字节 - Windows 上用
InterlockedCompareExchange替代，但注意其语义等价于__ATOMIC_ACQ_REL，比纯RELEASE重
std::span + std::vector 实现零拷贝读写接口
用户真正要的不是“实现环形缓冲区”，而是“怎么从它里面高效拿一段连续内存去传给 readv、send 或解码器”。硬塞一个 pop_front() 接口反而逼人拼碎片。
参数差异：get_write_span() 应返回最多两段连续内存（绕到开头的那部分），而 get_read_span() 同理；调用方按需处理 1 段或 2 段。
- 返回
std::span<const char></const>或std::span<char></char>，不暴露内部指针，也不触发拷贝 - 别用
std::string_view——它要求底层内存连续，环形缓冲区天然不满足 - 示例：若缓冲区大小为 8192，当前读位置 8190，剩余可读 5 字节，则
get_read_span()返回{buf + 8190, 2}和{buf, 3}两个 span - 性能影响：每次调用只算两次加法和一次比较，无分支预测失败风险；比“复制到临时 buffer”快 3–5 倍（尤其小包场景）
调试时最常漏掉的三个内存序陷阱
环形缓冲区崩溃往往不是越界，而是读到了未写完的数据，或者写了一半就被读走——这类问题在压力测试下才暴露，本地跑十次都正常。
容易踩的坑：
- 用
std::atomic<t>::store</t>但忘了指定 memory order，默认是__ATOMIC_SEQ_CST，过度同步拖慢 20%+；SPSC 下用__ATOMIC_RELEASE/__ATOMIC_ACQUIRE足够 - 以为
std::atomic_thread_fence能代替原子变量上的 order，其实 fence 是全局屏障，粒度太粗，且容易漏配对 - 在写入数据前没用
std::atomic_signal_fence(std::memory_order_release)（或编译器内置 barrier），导致编译器把数据写入指令重排到游标更新之后
复杂点在于：这些错误不会报错，只会让某个字段偶尔错一位，或者某次批量读少几个字节。得靠 valgrind --tool=helgrind 或 TSAN 才能抓到，光看逻辑是对的。
