container/list需封装判空逻辑才能安全模拟栈，否则Back()/Front()返回nil指针导致panic；container/heap需完整实现五个接口方法且Push/Pop必须指针接收者，修改元素后须调用heap.Fix维护堆序。
container/list 不能直接当栈用，必须封装判空逻辑
裸用 container/list 模拟栈，90% 的 panic 都出在空列表调 Back() 或 Front()。它返回 nil *list.Element，再点 .Value 就直接崩溃，错误信息是 panic: runtime error: invalid memory address or nil pointer dereference。
根本原因：list 是双向链表，没有栈语义约束。你 PushBack 入栈，却误用 Front() 查顶，拿到的是最早元素；或者连续两次 Remove(l.Back())，第二次操作的是已释放节点指针。
- 统一用
PushBack入栈、Back()查顶、Remove(Back())出栈——所有操作锚定尾部，行为可预测 - 每次调
Back()前必须写if l.Len() == 0判断，不能省 - 更稳妥的做法是封装成
Stack结构体，把判空、类型断言、节点操作全收进去，比如func (s *Stack) Pop() (interface{}, bool)
container/heap 要求实现全部五个接口方法，缺一不可
container/heap 不是“拿来即用”的堆类型，它只提供操作函数（heap.Init、heap.Push、heap.Pop），底层结构和比较逻辑全由你负责。编译器会严格检查是否实现了 Len、Less、Swap、Push、Pop 这五个方法，漏一个就报错。
常见翻车点：以为 Less 决定“谁小谁在顶”就完事了，结果忘了 Push 和 Pop 必须是指针接收者（因为要修改底层数组长度），写成值接收者会导致切片扩容不生效，后续 Push 直接 panic：index out of range。
-
Push必须用append扩容底层数组，且接收者为指针（func (h *IntHeap) Push(x interface{})） -
Pop必须返回末尾元素并截断数组（old := *h; n := len(old); x := old[n-1]; *h = old[0:n-1]），不是简单删第一个 -
Less(i, j int) bool中的i和j是数组下标，不是元素值；写反了（比如该写h[i] 却写了h[i] > h[j]）会导致最小堆变最大堆，但程序不报错，只逻辑错
修改 heap 中元素后必须调 heap.Fix，否则堆序失效
container/heap 不监听底层数组变化。如果你直接改了某个索引位置的值（比如 h[3] = 100），堆结构不会自动调整——下一次 heap.Pop() 可能返回错误的“最小值”，因为父子关系已破坏。
正确做法是：先用 heap.Remove 把旧元素删掉（它会自动维护堆序），再 heap.Push 新值；或者更高效地，直接调 heap.Fix(h, i)，它会以索引 i 为起点向上/向下堆化一次。
-
heap.Fix第二个参数是被修改元素在底层数组中的下标，不是值，也不是节点指针 - 如果不确定改的是哪个位置，或批量更新，老实用
heap.Remove + heap.Push组合，虽然略慢但绝对安全 - 别依赖
heap.Init重新初始化整堆来“兜底”——它时间复杂度是 O(n)，而Fix是 O(log n)
list 和 heap 的适用边界很清晰：栈用 list 封装，优先队列用 heap
别为了“看起来高级”硬套 container/heap 实现栈。它底层是切片+堆化，每次 Pop 都要重排，O(log n) 时间；而封装好的 list 栈是纯 O(1) 头尾操作。反过来，也别用 list 模拟优先队列——遍历找最小值是 O(n)，heap.Pop 是 O(log n)。
真正容易被忽略的是：list 的内存局部性差（链表节点分散分配），heap 的底层数组缓存友好。高频栈操作（比如解析器状态压入弹出）用 list 封装没问题；但若栈深度极大、又要求极致性能，就得考虑用切片手写栈，避免指针间接寻址开销。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
