List不能直接用索引访问元素，因其是链表，无连续内存和随机访问能力；正确做法是通过Front()和Next()遍历，频繁索引访问应改用切片或map。
为什么 List 不能直接用索引访问元素
container/list 是链表，不是数组或切片，底层没有连续内存和随机访问能力。想用 list[i] 或 list.At(i)？不存在——Go 标准库没提供这类方法。
常见错误现象：写完 list.Element.Value 却发现不知道怎么拿到第 3 个节点；或者试图用 for i := range list 编译失败（List 不支持 range）。
- 正确做法是用
list.Front()拿头节点，再反复调用next()走指定步数 - 如果频繁按索引查，说明数据结构选错了——改用
[]T或map[int]T - 遍历时优先用
for e := list.Front(); e != nil; e = e.Next()，比转成切片再遍历更省内存
插入新元素时，PushFront 和 InsertBefore 的行为差异
两者都往链表里加节点，但触发条件和参数意义完全不同：PushFront 总是插在最前面；InsertBefore 必须指定一个已有 *Element 作为锚点。
容易踩的坑：传给 InsertBefore 的 *Element 是 nil 或已从链表中移除的节点，会导致 panic（错误信息：panic: insert into nil list）。
立即学习“go语言免费学习笔记（深入）”；
-
PushFront/PushBack适合初始化或队列/栈场景 -
InsertBefore/InsertAfter适合维护有序链表、实现 LRU 中的“移到头部”逻辑 - 注意：
InsertBefore(e, v)是把v插到e前面，不是“把e插到v前面”——参数顺序容易看反
删除节点后，Element 的 Next() 和 Prev() 还能用吗
不能。一旦调用 list.Remove(e) 或 list.MoveToFront(e) 等操作，该 *Element 的 next 和 prev 字段会被清空（设为 nil）。继续调用 e.Next() 返回 nil，不会 panic，但逻辑会断掉。
典型误用场景：遍历时一边删一边用 e.Next() 取下一个节点，结果删完当前节点后，e.Next() 已失效，循环提前终止。
- 安全删除模式：先保存下一个节点
next := e.Next()，再删e，最后用next继续循环 -
Remove后别再对原*Element做任何链表操作（MoveBefore、Value读取仍可，但Next/Prev失效） - 如果需要复用节点，用
list.Init()重置整个链表，而不是手动恢复指针
为什么 List 的 Len() 是 O(1)，但 len([]T) 也是 O(1)？区别在哪
两者时间复杂度都是 O(1)，但原因不同：List.Len() 直接返回内部计数器字段；len(slice) 是编译器内建操作，读 slice header 的 len 字段。表面上一样快，实际使用中差别藏在别处。
关键差异在于：slice 的长度是值语义的一部分，而 List 的长度只是统计值，不反映结构稳定性。
-
List.Len()在并发修改时可能不准（标准库未加锁），多 goroutine 同时增删需自行同步 - slice 的
len是只读快照，哪怕底层数组正被其他 goroutine 修改，len值也不会变 - 别依赖
List.Len() == 0判断是否为空来做条件分支——它可能刚判断完就被另一个 goroutine 插入了元素
链表操作真正的复杂点不在 API 多少，而在所有涉及指针移动的动作（MoveToFront、Remove、InsertAfter）都会悄悄改写节点的 next/prev 字段——这些改动不可见，却直接影响后续遍历路径。稍不注意，就漏掉节点或无限循环。
