container/list 不该用于随机索引访问，因其底层为双向链表，无O(1)下标寻址能力，标准库也未提供ElementAt方法；真需索引访问应直接使用切片[]T。
为什么 container/list 不该用来做随机索引访问
因为它的底层是链式结构，没有数组那样的 O(1) 下标寻址能力。每次调用 list.ElementAt(i)（注意：这函数根本不存在）都得从头或尾开始遍历，实际是 O(n)，而且标准库压根没提供这个方法——很多人误以为有，结果写了个循环手动找，还觉得“只是慢点”。
- 真要按索引取值，直接用切片
[]T，别硬套list.List -
container/list只暴露了Front()、Back()、Next()、Prev()这类指针式操作，适合“游标移动”场景，不是“下标跳转”场景 - 如果你在循环里反复调用
l.Front()再elem.Next()走 i 步——性能会随长度线性恶化，且容易漏判nil
list.Element 是什么，为什么不能直接存值
list.Element 是链表节点的句柄，它不持有数据副本，只保存指向值的指针和前后节点引用。你往 list.PushBack(x) 传的 x 会被包装成 Element，但后续修改 x 本身不会影响链表里的内容——因为存的是当时那一刻的值或指针。
- 传基本类型（如
int）时，存的是值拷贝；传结构体时，也默认拷贝整个结构体，除非你显式传指针&myStruct - 误以为
elem.Value是可变引用？错。它是interface{}，取出后类型断言得到的是新变量，原节点里的值不会自动同步 - 常见坑：把一个局部变量地址反复
PushBack(&x)，然后在循环里改x，结果所有节点都指向同一个内存地址，最后全变成最后一次赋的值
插入/删除操作必须用 Element 指针，不能靠值匹配
container/list 没有类似 RemoveByValue(v) 的方法。它不比较值，只认节点指针。这意味着你不能说“删掉等于 42 的那个元素”，而必须先拿到那个 *list.Element，再调 list.Remove(elem)。
- 查找目标节点只能靠遍历 + 类型断言比对，比如
v, ok := elem.Value.(int); if ok && v == 42 { list.Remove(elem); break } - 如果频繁按值增删，说明数据模型和容器选型不匹配——考虑用
map[int]*list.Element做索引缓存，否则每次删都是 O(n) -
InsertBefore和InsertAfter也必须传已有Element，不能传位置序号或值；否则就只能先找节点再插，两步缺一不可
什么时候真的该用 container/list
只有当你明确需要高频、任意位置的 O(1) 插入/删除，且操作天然基于“当前节点”的上下文时，它才比切片或 map 更合适。典型如实现 LRU 缓存、事件队列中的中间取消、协程间传递带顺序的待处理项。
立即学习“go语言免费学习笔记（深入）”；
- LRU 里每次访问就把对应节点移到 Front，淘汰 Back 节点——全程只用
MoveToFront和Remove，不用索引也不用查找值 - 读写并发高？小心：
list.List本身不带锁，多 goroutine 同时操作必须自己加sync.Mutex或用sync.RWMutex - 别为了“看起来高级”而用；90% 的列表需求，
[]T配上append和切片截断更简单、更省内存、GC 压力更小
链表的灵活性是有代价的：每个元素额外带两个指针字段，分配更碎，缓存不友好。用之前先问自己——我是不是真的在操作“某个已知节点”的前后关系？如果不是，大概率不该用它。
