for e := l.front(); e != nil; e = e.next() 是唯一安全的正向遍历模式，因需从 front() 出发、每次调用 next() 实时获取后继、且必须判空；类型断言须用双值形式；边删边遍需缓存 next 指针。
container/list 的遍历不能用下标，也不能靠“移动 head 指针”那种写法——必须从 Front() 或 Back() 出发，靠 Next() / Prev() 一步步走，且每次都要检查指针是否为 nil。
为什么 for e := l.Front(); e != nil; e = e.Next() 是唯一安全的正向遍历模式
因为 l.Front() 返回的是 *list.Element 类型，它本身不带“下一个”的快照；e.Next() 每次调用都实时读取当前节点的 next 字段。如果写成类似 for n := head.Next; n != nil; head = n 这种结构，n 只在循环开始时计算一次，后续不会更新，导致无限循环或跳过节点。
- 错误示范：
for n := l.Front().Next(); n != nil; n = n.Next()—— 一开始就跳过了头节点 - 正确起点必须是
l.Front()，不是l.Front().Next() - 循环条件里不能省略
e != nil，空链表的l.Front()就是nil
遍历时取值必须做类型断言，且推荐双值形式
Element.Value 是 interface{}，Go 不会自动转换。直接写 e.Value.(int) 在类型不符时会 panic，生产环境务必用双值断言。
- 危险写法：
sum += e.Value.(int)—— 若链表混入string或nil，运行时崩溃 - 安全写法：
if v, ok := e.Value.(int); ok { sum += v } - 若需支持多种类型，建议提前约定并统一处理逻辑，不要在遍历中动态判断类型分支
边遍历边删除必须缓存 next 指针
调用 l.Remove(e) 后，e.Next() 可能返回 nil（尤其当 e 是末尾节点），导致循环提前退出。解决办法是在删除前把下一个节点存下来。
- 错误写法：
for e := l.Front(); e != nil; e = e.Next() { if shouldRemove(e) { l.Remove(e) } }—— 删除后e.Next()失效 - 正确写法：
for e := l.Front(); e != nil; { next := e.Next(); if shouldRemove(e) { l.Remove(e) }; e = next } - 注意：删除操作不改变
e自身，但会切断它与前后节点的连接，所以必须提前抓取next
反向遍历和 container/ring 的 Do 方法不适用于 container/list
container/list 没有 Do 方法，也不支持像 ring 那样用固定长度 + 循环索引遍历。Back() + Prev() 是唯一反向路径，逻辑对称但别和正向混用。
- 反向正确写法：
for e := l.Back(); e != nil; e = e.Prev() { ... } - 误用
ring.Do会编译失败：该方法只属于container/ring，和list无关 - 别试图用
l.Len()控制循环次数来遍历 ——Len()是 O(1)，但遍历本身仍是 O(n)，且无法保证中间不被并发修改
最易被忽略的一点：你拿到的永远是 *list.Element，不是数据本身；所有逻辑都得围绕这个指针展开，而不是幻想它像 slice 那样可随机访问或批量操作。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
