container/list 不适合大多数场景，因其泛型缺失、接口抽象过重、性能不透明，日常应优先使用切片或自定义结构体；其 pushback 返回 *list.element 是因所有操作依赖该节点句柄，且不支持索引访问与值拷贝语义。
Go 标准库的 container/list 不适合大多数场景，它泛型缺失、接口抽象过重、性能不透明，日常开发中建议优先用切片或自定义结构体。
为什么 container/list 的 PushBack 返回 *list.Element 而不是值？
因为 list.Element 是链表节点的句柄，所有增删查改操作都依赖它——container/list 不提供按索引访问，也没有值拷贝语义。你存进去的是值的副本，但后续操作必须通过 *Element 指针完成。
- 常见错误：存完就丢掉返回的
*Element，后面想Remove或MoveBefore就只能遍历找，O(n) 且易出错 - 正确做法：把
*Element和业务数据一起存（比如放进 struct 字段或 map），尤其在需要频繁移动/删除特定项时 - 注意：
Element.Value是interface{}，类型断言失败会 panic，务必检查ok
container/list 在循环中调用 Next() 为什么容易漏项或死循环？
因为 Next() 返回 nil 表示到尾，但如果你在循环体里删了当前节点，它的 Next() 可能已失效；更隐蔽的是，从头开始遍历时误用 for e != nil 却忘了更新 e = e.Next()。
- 安全遍历写法：用
for e := l.Front(); e != nil; e = e.Next()，且遍历时禁止直接l.Remove(e) - 要边遍历边删？改用
for e := l.Front(); e != nil;，然后在循环内做next := e.Next(); l.Remove(e); e = next - 别用
range：它底层不支持container/list，编译不过
用 container/list 实现 LRU 缓存时，MoveToFront 的坑在哪？
MoveToFront 只接受 *Element，但很多人误以为传入值就能自动查找——它不会搜索，传错指针或已删除的元素会导致静默失败或 panic。
立即学习“go语言免费学习笔记（深入）”；
- 典型错误：缓存命中后，用新值
PushFront再删旧节点，导致重复数据 + 内存泄漏 - 正确逻辑：查到命中项 → 用其
*Element调MoveToFront→ 更新Value字段（不是重新赋值） - 性能提示：标准库 list 查找仍是 O(n)，真要高性能 LRU，请用
map[string]*list.Element辅助索引
真正难的不是怎么调 PushBack 或 Remove，而是意识到：一旦你需要随机访问、稳定迭代顺序、或明确的内存布局，container/list 就成了负优化。它的存在更多是为标准库内部服务，而非你的业务代码。
