Golang双向链表List操作详解

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）。

• 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 字段——这些改动不可见，却直接影响后续遍历路径。稍不注意，就漏掉节点或无限循环。