container/list本质是带头节点的双向循环链表，空链表时root.next和root.prev互指，非空时头尾闭环；遍历时若仅用e!=nil判断会无限循环，须结合长度或判等终止。
Go 标准库没有提供“双向循环链表”的独立类型，但 container/list 本质就是带头节点的双向循环链表；而 container/ring 是无头节点、纯节点级的双向循环链表——二者结构语义不同，不能混用或替代。
为什么 container/list 看似线性实为循环？
它的 Front() 和 Back() 返回的 *list.Element 指针，其 next 和 prev 字段在空链表时互指，在非空时构成闭环：头节点的 prev 指向尾节点，尾节点的 next 指向头节点。这不是文档“暗示”，而是源码明确实现（l.root.next = &l.root; l.root.prev = &l.root）。
常见错误现象：
- 遍历时用
e != nil判断终止，结果无限循环——因为循环链表里永远没有nil的next/prev（除非手动断开） - 误以为
PushFront插入后Front().Prev()是nil，实际它指向尾节点
正确遍历写法必须带计数或判等：
立即学习“go语言免费学习笔记（深入）”；
for e := l.Front(); e != nil && e != l.Back().Next(); e = e.Next() { ... }
或更稳妥地用长度控制：
n := l.Len(); for i := 0; i < n; i++ { e := l.Front(); l.MoveToBack(e); ... }
container/ring 的 Next()/Prev() 行为与 list 完全不同
ring.New(n) 创建的是一个固定长度的环，所有节点初始值为 nil，且不封装数据逻辑——它只管指针跳转，不管“头尾”“空值”“插入位置”。你必须自己管理节点内容和遍历边界。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
使用场景：
- 固定窗口滑动（如最近 N 条日志缓存）
- 轮询调度器（如负载均衡中轮询后端节点）
- 需要 O(1) 随机起点遍历的环形缓冲区
容易踩的坑：
- 调用
r.Value = x不会自动移动r指针，下次r.Next()还是原节点——必须显式r = r.Next() -
ring.Do()是无状态遍历，无法中途退出或修改当前节点指针 - 没有长度字段，
Len()是 O(n) 遍历计数，别在热路径调用
手写泛型双向循环链表时，root 节点的初始化必须自指
这是循环性的唯一来源。若漏掉 root.next = &root; root.prev = &root，整个结构退化为普通双向链表，所有基于“绕回”逻辑的操作（如尾插、环形索引计算）都会崩溃或死循环。
性能影响明显：
- 有了自指
root，尾节点即root.prev，尾插/尾删都是 O(1)，无需遍历找尾 - 插入任意位置只需改 4 个指针：
at.next、at.next.prev、new.next、new.prev - 删除同理，只需改
del.prev.next和del.next.prev
示例关键片段：
func (l *List[T]) insertAfter(at *Node[T], v T) {
n := &Node[T]{Value: v, prev: at, next: at.next}
at.next.prev = n
at.next = n
l.len++
}
语言学习中处理复杂结构，最易忽略的是“循环不变量”的维护时机
比如在泛型链表中实现 Rotate(n)：把前 n 个元素移到末尾。看似只是改几处指针，但若在修改过程中临时破坏了 root.next == tail.next 或 root.prev == head.prev 这类关系，遍历就会断裂。
真正难的不是写对某一次操作，而是在所有增删改查入口统一保证：root.next.prev == &root 且 root.prev.next == &root。这个条件一旦松动，后续任何基于循环假设的代码都不可靠。
