不能直接用list.append()做流式环形缓冲，因其会无限制扩容，违背固定容量与自动覆盖最老数据的环形语义；应选用collections.deque(maxlen)、手写索引类或NumPy数组实现。
为什么不能直接用 list.append() 做流式环形缓冲
因为 list.append() 在满容量后继续追加会无限制增长，失去“环形”语义；而真实流场景（如传感器采样、音频帧缓存）要求固定内存占用 + 自动覆盖最老数据。Python 标准库没有内置 Ring Buffer，但可以用 collections.deque 或手动维护索引实现，前者更安全，后者更可控。
常见错误是误用 deque(maxlen=N) 后还调用 pop() 或 remove() —— 这会破坏自动截断逻辑，导致长度异常或 IndexError。
- 用
deque(maxlen=N)时，只通过append()/appendleft()写入，读取用索引（如d[0]、d[-1]）或迭代 - 避免混用
extend()：如果传入长度 >maxlen的可迭代对象，deque 会先清空再填满，行为不符合“逐个覆盖”的直觉 - 注意线程安全：deque 本身不是线程安全的，多线程写入需加
threading.Lock
手动实现带读写指针的 RingBuffer 类
当需要精确控制读写位置（比如生产者/消费者不同步、支持批量读取或跳读），手动实现更合适。核心是两个整数指针 self._write_idx 和 self._read_idx，配合取模运算实现循环。
关键陷阱在于“空 vs 满”的判断：容量为 N 的数组，仅靠两个指针无法区分空和满（都会出现 read_idx == write_idx）。标准解法是牺牲一个槽位，或额外维护 self._size。
立即学习“Python免费学习笔记（深入）”；
- 推荐维护
self._size：避免歧义，且len()、is_empty()、is_full()都能 O(1) 实现 - 写入时先检查是否满，满则可选择抛出异常、丢弃新数据、或覆盖最老数据（即
self._read_idx = (self._read_idx + 1) % self._capacity） - 读取单个元素后，必须更新
_read_idx和_size；批量读取（如read(n)）要处理跨尾部边界的情况，用切片拼接：self._buffer[self._read_idx:] + self._buffer[:new_read_idx]
NumPy 版 RingBuffer 用于高性能数值流
如果缓冲区存的是 float32 音频样本、int16 传感器值等同构数值，用 NumPy 数组比 list 或 deque 快 5–10 倍，且支持向量化操作（如实时计算均值、FFT 窗口）。
注意 numpy.ndarray 不支持自动环形索引，必须显式用取模：例如写入第 i 个位置，用 buf[i % capacity]；但更高效的是预计算索引数组或用 np.roll()（仅适合小规模更新，否则拷贝开销大）。
- 初始化用
np.empty(capacity, dtype=np.float32)，避免 fill 初始化开销 - 避免频繁调用
np.concatenate()拼接跨边界读取结果——改用np.take(buf, indices, mode='wrap')，indices 是np.arange(start, start+n) % capacity - 如果需实时统计（如滑动窗口标准差），优先用
numba.jit加速指针更新逻辑，而非依赖 pandas 或纯 Python 循环
选型对比：deque / 手写类 / NumPy 各适合什么场景
没有银弹。deque(maxlen=N) 最适合简单缓存（如最近 N 条日志）、原型验证；手写 RingBuffer 类适合嵌入式对接、需要自定义溢出策略（如触发回调）或与 C 扩展交互；NumPy 版本只在纯数值计算密集型流中体现价值。
容易被忽略的一点：GC 压力。deque 在高频写入（>10kHz）下会产生较多临时对象，而手写类和 NumPy 版本几乎零分配——这点在长期运行的服务中会影响延迟稳定性。
