container/ring 是双向循环链表而非环形缓冲区，误用会导致内存泄漏、逻辑错误或性能问题；其 len() 方法时间复杂度为 o(n) 且不反映逻辑容量，move() 和 next() 易引发越界或遍历异常；推荐用 slice + 游标实现真正 ring buffer。
container/ring 不是环形缓冲区，它是双向循环链表。拿它当 ring buffer 用，大概率会内存泄漏、逻辑错乱或性能掉坑里。
为什么 container/ring.Len() 不能判断缓冲区是否满
Len() 是遍历一圈数节点个数，时间复杂度 O(n)，且返回的是物理节点总数，不是你“逻辑上”想管理的缓冲区长度。你初始化 ring.New(10) 得到 10 个节点，但如果你反复 Link() 新节点，Len() 就会越来越大——它不阻止你扩容，也不代表容量上限。
- 误用示例：
if r.Len() >= cap { /* 满了 */ }—— 实际可能早溢出几十个节点了 - 真正需要的“满”，是写入位置追上读取位置，而
ring.Ring根本没存 head/tail 这类游标 - 若真要用
Len()做控制，必须手动维护一个独立 size 计数器，并在每次Link()/Unlink()后同步更新
ring.Move() 和 ring.Next() 的行为容易引发越界或绕圈 bug
Move(n) 是从当前节点出发，绝对移动 n 步（正为顺时针，负为逆时针），不是“移到第 n 个有效数据位”。它不检查边界，也不感知哪些节点是你“逻辑上”认为有效的。
-
r.Move(-1)不等于r.Prev()：前者可能绕好几圈，后者只走一步 - 常见错误：用
Move(k)模拟索引访问，结果 k 超出预期范围，指针跑到旧数据甚至空节点上 - 遍历时若中途修改结构（如
Unlink()），再调Move()可能 panic 或跳过元素
用 slice + 取模实现 ring buffer 才符合直觉和性能需求
固定容量、自动覆盖、O(1) 头尾操作、缓存友好——这些才是 ring buffer 的刚需。用 []int 配合两个整数游标，比 container/ring 更可控。
- 容量设为 2 的幂（如 128），用
idx & (cap - 1)替代idx % cap，避免除法开销 - 写入前检查是否满：
(write+1)&(cap-1) == read表示满（预留一位避免空满同态） - 负数取模要小心：
-1 % 5在 Go 中是-1，安全写法是(x+cap)%cap - 别暴露
head/tail字段，封装成Push()/Pop()方法，内部做原子性检查
container/ring 唯一适合的场景：你需要旋转视图，而不是队列语义
比如命令行历史浏览（↑/↓ 键前后翻）、协程轮转调度器、LRU 缓存的手动索引——这些场景不关心“容量上限”或“自动丢弃”，只依赖 Next()/Prev() 的天然循环性和节点可动态增删的灵活性。
- 这时
ring.Move()和Do()才真正省事 - 但注意：每个节点是堆分配的
*ring.Ring，高频小对象写入会加重 GC 压力 - 多 goroutine 并发读写必须自己加锁，
container/ring本身完全不提供并发安全保证
真正做日志缓冲、网络包暂存、滑动窗口采样，别碰 container/ring。哪怕手写 30 行 slice 版本，也比用错链表强得多——最易被忽略的是：你以为在管理缓冲区，其实只是在给链表不断打补丁。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
