container/list 节点删除必须显式调用 list.Remove()，仅置 e = nil 无效；遍历时需先保存 next 再 Remove；Value 内存需手动管理，无自动 GC 清理。
container/list 的节点删除必须手动调用 list.Remove()
Go 标准库的 container/list 不提供自动 GC 式的“懒删除”，节点不会因被变量引用消失就自动从链表中脱离。哪怕你把指向 *list.Element 的变量置为 nil，只要它还在链表里（即 element.Next() != nil 或 element.Prev() != nil），它就仍参与遍历、仍占用内存、仍影响长度统计。
正确做法是显式调用 list.Remove()：
l := list.New()
e := l.PushBack("hello")
// ... 后续想删掉这个节点
l.Remove(e) // ✅ 必须这一步
e = nil // ❌ 单独这步无效
常见误操作：
- 只设
e = nil，误以为“释放了节点”——实际链表结构未变，l.Len()不减，遍历时仍会访问到该节点 - 重复调用
l.Remove(e)—— 第二次会 panic：panic: runtime error: invalid memory address or nil pointer dereference（因为e.next和e.prev已被清空） - 在遍历中直接
Remove()当前元素但没保存next，导致漏遍历后续节点（见下节）
遍历中安全删除节点要先保存 next
list.Front() → element.Next() 遍历是常见模式，但如果在循环体里调用 l.Remove(e)，会断开 e 的前后指针，导致 e.Next() 返回 nil，下一次迭代直接中断。
立即学习“go语言免费学习笔记（深入）”；
正确写法是：在调用 Remove() 前，先把下一个元素存下来：
for e := l.Front(); e != nil; {
next := e.Next() // ✅ 先取 next
if shouldDelete(e.Value) {
l.Remove(e)
}
e = next // ✅ 再移动指针
}
注意：list.Remove() 不会修改其他节点的指针，只清理目标节点的 next/prev，所以 next 在 Remove(e) 后依然有效。
list.Element.Value 是 interface{}，清理时需注意底层数据生命周期
container/list 本身不管理 Value 指向的数据内存，只负责链表结构。如果你存的是大对象指针（比如 *[]byte 或自定义 struct 指针），删除节点后，若没有其他引用，GC 才能回收；如果存的是大 slice 或 map 值类型，它们本身就在节点内存里，Remove() 后随 Element 结构一起被 GC。
典型风险场景：
- 存了指向全局缓存的指针，删除节点却忘了从缓存中解绑 → 内存泄漏
- 存了
unsafe.Pointer或 C 内存地址，Remove()后未手动C.free→ C 层内存泄漏 - 存了闭包或含引用的函数值，且该函数被长期持有 → 隐式引用泄漏
没有银弹，得根据 Value 的实际类型决定是否需要额外清理动作。
替代方案：用切片模拟链表更可控？
如果业务中频繁增删中间节点、又不需要双向遍历或 O(1) 插入任意位置，[]T + append()/copy() 可能比 container/list 更简单、内存更紧凑、GC 更友好。例如删除索引 i 处元素：
slice = append(slice[:i], slice[i+1:]...)
但要注意：container/list 的真实价值在于：保留插入顺序、支持多 goroutine 安全（配合 mutex）、以及 Element 可跨操作复用（比如一个元素可在多个 list 间移动）。盲目替换可能引入新问题。
真正难的不是“怎么删”，而是删完之后，那个 Value 谁来负责、什么时候释放、有没有外部强引用——这些都不会在 l.Remove() 里自动发生。
