双向链表节点必须用指针而非嵌套结构体，因Go禁止自引用类型且语义上需共享内存；InsertBefore/After需先设新节点指针再更新邻居，空链表时Prev/Next均置nil；遍历时仅判nil不安全，须防环和非法地址。
为什么双向链表的节点必须用指针，不能直接嵌套结构体？
因为 Go 中结构体赋值是值拷贝，如果 Node 里直接放另一个 Node 字段（比如 Next Node），编译器会报错：invalid recursive type Node —— 类型定义自引用不被允许。必须用指针打破循环依赖。
更关键的是语义：双向链表的“连接”本质是引用关系，不是数据复制。用 *Node 才能共享同一份内存，让多个节点指向同一个目标节点。
-
type Node struct { Val int; Prev, Next *Node }✅ 合法且符合逻辑 -
type Node struct { Val int; Prev, Next Node }❌ 编译失败，且语义错误 - 即使绕过编译（比如用接口或空结构体占位），运行时也会因无限递归导致栈溢出
InsertBefore 和 InsertAfter 的边界处理怎么写才不 panic？
核心在于：插入操作前必须检查目标节点是否为 nil，且要同步更新前后节点的指针，顺序错一点就断链。
典型错误是忽略头尾节点的特殊性 —— 比如在头节点前插入时，新节点成了新头，但忘了更新原头节点的 Prev；或者插入到空链表时，没把 Prev 和 Next 都设为 nil。
立即学习“go语言免费学习笔记（深入）”；
- 统一做法：先处理新节点自身的
Prev和Next，再更新邻居节点的指针 - 插入到
nil节点（即空链表）时，新节点的Prev和Next必须都为nil - 插入到头节点前：原头节点的
Prev要指向新节点；新节点的Next指向原头；若链表有头指针变量（如head *Node），记得更新它
示例（插入到某节点前）：
func (n *Node) InsertBefore(v int) *Node {
newNode := &Node{Val: v}
newNode.Next = n
newNode.Prev = n.Prev
if n.Prev != nil {
n.Prev.Next = newNode
}
n.Prev = newNode
return newNode
}
遍历双向链表时，为什么不能只靠 Next 就认为安全？
因为双向链表可能被意外破坏：某个节点的 Prev 或 Next 被设为非法地址（比如已释放的指针、0x0 以外的野地址），但 Go 的 nil 检查只能拦住 nil，拦不住其他非法值。更常见的是逻辑错误导致环 —— 比如插入时没清掉旧指针，形成自环或循环链，for n != nil { n = n.Next } 就永远停不下来。
- 安全遍历必须加步数限制或访问标记（尤其在测试或调试时）
- 生产环境建议封装成方法，内部用
for n != nil && count 防止死循环 - 反向遍历（从尾往头）同样要检查
Prev是否为nil，不能默认和Next对称 - 如果链表带长度字段，遍历时可用长度做上限；否则至少加一个保守上限（如 1e6）
删除节点时，Prev 和 Next 的置空顺序会影响 GC 吗？
不影响 GC 判定，但影响链表结构的即时一致性。Go 的垃圾回收器只看是否有活跃的根引用，不关心指针是否被显式置 nil。但不及时清理会导致：1）其他代码误读残留指针造成 panic；2）调试时看到“幽灵链接”，以为没删干净。
- 正确顺序：先更新邻居节点的指针（让它们跳过当前节点），再把当前节点的
Prev和Next设为nil - 特别注意：如果节点是头或尾，删除后要更新外部的头/尾指针变量（如
list.head = node.Next） - 不要写
node = nil—— 这只是改了局部变量，不影响堆上原结构体 - 如果节点被多个地方引用（比如缓存、map），仅断链不够，需确保所有引用都被清除，否则无法 GC
事情说清了就结束。真正难的不是写对四个指针，而是每次修改都得同时脑内模拟前后两个方向的三节点关系——稍一走神，Prev 和 Next 就对不上了。
