container/list 不能直接当栈用，因其是双向链表、无LIFO约束、易误操作导致非栈行为或panic；应封装为Stack结构体，统一用PushBack/Back/Remove并判空。
为什么不能直接用 container/list 当栈用
因为 container/list 是双向链表，没有内置的栈语义——它不保证你总在尾部压入、头部弹出，也不防你误操作中间节点。一旦写错方向（比如用 PushFront 压入却用 Back 取值），就不是 LIFO 了。
常见错误现象：list.Front().Value 返回的却是最早插入的元素，但你以为是最新压入的；或者反复 Remove 同一个节点导致 panic。
- 栈必须严格限定“只在一头进出”，
container/list默认不强制这个约束 - 它的
PushFront/PushBack行为对称，选哪边做“栈顶”全靠人记住，容易混淆 - 没有空栈检查逻辑，
Front()在空列表上返回nil，直接取.Value会 panic
PushBack + Back + Remove 是最稳的组合
选尾部（Back）作为栈顶，统一用 PushBack 入栈、Back 查顶、Remove 出栈。这样所有操作都集中在链表末端，缓存局部性略好，且和多数人直觉一致（“最后加的在最上面”）。
使用场景：需要轻量、无泛型限制的栈（比如暂存临时解析状态、回溯路径），又不想引入第三方包。
立即学习“go语言免费学习笔记（深入）”；
-
l.PushBack(x)入栈 —— 总在尾部追加 -
l.Back().Value查栈顶 —— 但必须先判断l.Len() > 0 -
l.Remove(l.Back())出栈 —— 注意：必须传入节点指针，不是值 - 别用
l.Front()配PushBack()，那其实是队列行为
示例：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
l := list.New()
l.PushBack(1)
l.PushBack(2)
if l.Len() > 0 {
top := l.Back().Value // 2
l.Remove(l.Back()) // 弹出 2
}
空栈访问 panic 的典型触发点
最常被忽略的是没检查长度就调 Back() 或 Front()。Go 的 list 不会在空时返回默认值，而是返回 nil *节点指针*，再解引用 .Value 就直接 crash。
错误信息类似：panic: runtime error: invalid memory address or nil pointer dereference
- 永远在
Back()/Front()前加if l.Len() == 0判断 - 不要依赖
recover捕获这种 panic——它本该是编译期/逻辑期发现的问题 - 如果封装成函数，把判空逻辑收进去，比如
func (s *Stack) Pop() (interface{}, bool)
比原生 list 多一步封装才真正可靠
裸用 container/list 写栈，每次都要重复判空、类型断言、节点操作，既啰嗦又易错。真正省心的做法是包一层薄结构体，把“栈”的契约固化下来。
性能影响几乎为零：只是多一次方法调用和字段访问，无额外内存分配；兼容性也没问题，Go 1.0 就支持 container/list。
- 字段只需一个
*list.List，不用额外切片或数组 - 导出方法名用
Push/Pop/Peek，语义清晰，不暴露底层list接口 -
Pop和Peek返回(interface{}, bool)，让调用方自己处理空栈分支 - 避免在结构体里存
list.Element指针——它们会随列表变更失效
事情说清了就结束。
