单向链表节点必须用指针类型定义，因为Go结构体值拷贝会导致无限嵌套和编译报错（invalid recursive type），只有*Node才能形成引用关系，避免内存大小无法计算。
为什么单向链表的节点必须用指针类型定义
因为 Go 的结构体赋值是值拷贝，如果 Node 字段直接存另一个 Node，会导致无限嵌套和编译报错。必须用 *Node 才能形成“指向下一个节点”的引用关系。
常见错误现象：invalid recursive type Node —— 这是编译器在告诉你：你试图让结构体包含自身值类型，它无法计算大小。
正确做法是把 next 字段声明为指针：
type Node struct {
Val int
Next *Node // ✅ 必须是指针
}
- 不能写成
Next Node（编译失败） - 也不建议用
Next *Node但初始化时漏掉&Node{...}，会导致 nil panic - 所有插入、遍历操作都基于
*Node，传参和返回也应统一用指针
插入节点时最容易忽略的 nil 检查
在头部插入（InsertHead）或遍历时，第一件事不是操作 Next，而是确认当前节点非 nil。否则一碰 node.Next 就 panic。
立即学习“go语言免费学习笔记（深入）”；
典型错误场景：空链表调用 InsertAfter，传入的 prev 是 nil，却直接执行 prev.Next = newNode。
实操建议：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 所有接受
*Node参数的函数，开头加if prev == nil { return }或明确文档说明不接受 nil - 头部插入不要写
head = &Node{Val: v, Next: head}，而要写*head = Node{Val: v, Next: *head}（如果 head 是**Node）或者更常见的：函数返回新头指针func InsertHead(head *Node, v int) *Node - 遍历循环条件必须是
curr != nil，不是curr.Next != nil（后者会漏掉最后一个节点）
遍历与修改链表时别意外丢失原链表头
Go 没有引用传递，*Node 本身仍是值——它存的是地址，但变量仍可被重新赋值。如果你写 head = head.Next，只是改了局部变量 head，不影响调用方的原始指针；但若想修改原始头节点内容（比如清空），就得用 **Node 或返回新头。
性能影响：用 **Node 虽能原地改头，但增加一层解引用，且易读性下降；多数情况推荐返回新头，语义更清晰。
示例对比：
// ❌ 错误：以为修改了外部 head，其实只是改了形参
func DeleteHead(head *Node) {
if head == nil {
return
}
head = head.Next // 这里只改了函数内的 head 变量
}
// ✅ 正确：返回新头，由调用方决定是否更新
func DeleteHead(head *Node) *Node {
if head == nil {
return nil
}
return head.Next
}
为什么不用 slice 代替链表
这不是“能不能”，而是“该不该”。slice 底层是数组，append 在容量不足时会分配新底层数组并拷贝——对频繁中间插入/删除的场景，时间复杂度是 O(n)，和链表一样；但链表每次操作只改几个指针，内存局部性差，cache 不友好。
真实使用场景有限：
- 需要稳定 O(1) 头部插入/删除，且不关心随机访问 → 链表合适
- 实际项目中绝大多数情况用
[]int+append/copy更简单、更快、更安全 - 标准库
container/list是双向链表，但因接口开销和 GC 压力，性能反而常不如 slice - 自己实现单向链表，90% 的用途是学习指针和内存模型，不是为替代 slice
容易被忽略的一点：链表节点分散在堆上，GC 扫描压力比连续 slice 大得多，尤其节点多时。真要高性能，先 benchmark，别凭直觉选链表。
