Go不推荐手写指针链表，因container/list已提供高效双向链表，且切片在多数场景更安全、更快；手写易致panic、缓存不友好、GC协同差。
为什么 Go 里不推荐手写指针链表
Go 标准库没有提供类似 C 那样的 struct node { int val; *node next } 手动管理的链表，根本原因不是语言做不到，而是没必要——container/list 已经是双向链表的成熟实现，且 []T 切片在绝大多数场景下比链表更高效、更安全。
如果你正试图用指针模拟链表，大概率是因为：误以为“链表插入快就该优先用”，或正在学习数据结构原理。前者建议直接用切片或 container/list；后者可以写，但必须清楚代价：
- 手动内存管理无意义（Go 有 GC，
*Node不会逃逸就未必堆分配） - 遍历性能差（缓存不友好，指针跳转开销明显）
- 易引入空指针 panic：
nil.next直接崩溃，而切片越界是 recoverable panic - 无法和 Go 生态工具链协同（比如
json.Marshal对自定义指针结构支持弱）
如何正确使用 container/list 实现链表逻辑
container/list 是标准库提供的双向链表，元素类型为 *list.Element，值存于 Element.Value 字段，类型为 interface{}。它不暴露指针细节，但提供了完整的链表操作语义。
常见误用是反复断开重连节点导致性能退化。正确做法是复用 *list.Element 或批量操作：
立即学习“go语言免费学习笔记（深入）”；
- 插入新值用
l.PushBack(123)或l.InsertAfter("x", someElem)，返回新*list.Element - 修改已有节点值：直接赋值
elem.Value = "new"，无需删除重建 - 遍历务必用
for e := l.Front(); e != nil; e = e.Next()，别用索引或转切片 - 如果需要类型安全，封装一层：定义
type IntList struct { *list.List }，再加PushBackInt(n int)方法
示例：在头部插入字符串并取第二个元素值
l := list.New()
l.PushFront("a")
l.PushFront("b") // b -> a
e := l.Front().Next() // 指向 "a"
if e != nil {
fmt.Println(e.Value.(string)) // 输出 "a"
}
真要手写指针链表时怎么避免 panic 和内存泄漏
若教学或特殊场景必须实现单向链表，核心是把 nil 判断变成“默认路径”而非异常分支，并避免意外保留对已移除节点的引用。
关键点：
- 定义节点结构时，显式初始化指针字段：
next: nil，不要依赖零值（虽 Go 会做，但可读性差） - 所有指针解引用前加
if node == nil检查，尤其node.next和node.prev - 删除节点后立即将其
next和prev置为nil，防止循环引用阻碍 GC - 避免在方法中返回内部节点指针（如
func (l *List) Get(i int) *Node），这会让调用方绕过链表控制逻辑
一个最小可用单链表节点定义：
type Node struct {
Val int
Next *Node
}
func (n *Node) Append(v int) {
if n.Next == nil {
n.Next = &Node{Val: v}
} else {
n.Next.Append(v)
}
}
注意：这个 Append 是递归的，深度大时可能栈溢出；生产环境应改用迭代。
什么时候该放弃链表，改用切片或 map
真实项目中，95% 的“我以为需要链表”的场景，实际只需要：
- 频繁尾部增删 → 用
[]T，append()和s = s[:len(s)-1]均摊 O(1) - 按 key 快速查找/更新 → 用
map[K]V，O(1) 平均复杂度 - 需要稳定迭代顺序 + 插入中间 → 先用切片，插入时
append(s[:i], append([]T{v}, s[i:]...)...)；若插入极频繁且长度 > 10k，再考虑container/list - 需原子性多节点操作（如“把 A 后面三个节点移到 B 前面”）→
container/list提供MoveBefore/MoveAfter，切片做不到
链表唯一不可替代的场景是：要求任意位置插入/删除严格 O(1)，且不能接受切片复制开销，同时数据规模足够大到让缓存失效成本低于复制成本——这种场景在 Go 服务中极少出现。
