Go 中无需手写链表或树：container/list 满足多数链表需求，map+struct 或 gods 更稳；仅算法题、教学或特殊约束时才手写。手写易 panic 的主因是空指针解引用与边界漏判，正确做法是传指针、判空、循环终止于 curr.Next != nil。
Go 语言里真没必要手写链表或树来干活——container/list 能 cover 90% 的链表需求，map + struct 或第三方库（如 gods）比手写二叉搜索树更稳；只有算法题、教学、或对内存/类型有硬性约束时，才值得自己定义 Node。
为什么手写单链表容易 panic？
最常掉坑的地方是空指针解引用和边界漏判：
-
head == nil时直接访问head.Next→panic: invalid memory address - 尾插逻辑写成
for curr != nil { curr = curr.Next }，结果循环结束时curr是nil，再执行curr.Next = newNode就崩了 - 头插没更新
head指针，后续遍历从旧地址开始，新节点永远进不去 - 函数传参用值传递（
func insert(head Node, v int)），改了形参不影响原链表
正确做法：所有操作函数必须接收 *Node 或 **Node，插入前必判 head == nil，尾插循环终止条件是 curr.Next != nil，最后一步才赋 curr.Next = newNode。
container/list 遍历时删节点为什么会丢元素？
因为 e.Next() 返回的是「当前节点在链表中的下一个节点」，但一旦你调用 l.Remove(e)，该节点就从链表中断开，e.Next() 的返回值可能已失效——尤其当 e 是最后一个节点时，e.Next() 原本指向 head（循环链表）或 nil（普通链表），移除后这个链接关系被破坏。
立即学习“go语言免费学习笔记（深入）”；
安全写法只有两种：
- 提前备份：
next := e.Next(); l.Remove(e); e = next - 不用 for 头部更新：
for e := l.Front(); e != nil; { next := e.Next(); /* do something with e */; e = next }
别信“先 Remove 再 Next 就没事”——e.Next() 在 Remove 后的行为未定义，Go 运行时不保证它还能返回有效节点。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
手写二叉树遍历时递归栈溢出怎么办？
不是 Go 的问题，是你没控制深度。纯递归中序/前序遍历一棵 10 万层的退化树（链状），会吃光默认 goroutine 栈空间（2MB），触发 runtime: goroutine stack exceeds 1000000000-byte limit。
- 生产环境别用纯递归遍历未知深度的树；改用显式栈（
[]*TreeNode）模拟迭代 - 如果必须递归，加深度计数器，超过阈值（比如 10000）就 panic 或 fallback 到迭代
-
TreeNode定义里别嵌套大结构体（比如含[]byte{1），否则单个节点就占几 MB，几层就爆栈
示例迭代中序：
func inorderIterative(root *TreeNode) {
var stack []*TreeNode
curr := root
for curr != nil || len(stack) > 0 {
for curr != nil {
stack = append(stack, curr)
curr = curr.Left
}
curr = stack[len(stack)-1]
stack = stack[:len(stack)-1]
fmt.Println(curr.Val)
curr = curr.Right
}
}循环链表的终止条件怎么写才不卡死？
不能只靠 curr.Next != head，因为初始时 curr == head，第一次判断就跳过循环体；也不能只靠 curr != head，因为刚进循环时 curr 就是 head，直接 break。
标准解法是「先做，再判」：
- 检查空：
if head == nil { return } - 设
curr := head - 进入
for循环体后，先处理curr，再更新：curr = curr.Next - 循环条件写成
curr != head，这样第一次不会进，但第二次起能覆盖全环
更稳妥的做法是加长度保护（尤其调试阶段）：count := 0; for count ，避免因环断裂导致无限循环。
真正难的从来不是写对一个 Next 指针，而是想清楚：这个链表会不会为空、有没有环、谁负责释放内存、并发读写要不要加锁——这些地方一模糊，代码跑着跑着就停在某个 nil 上，而 panic 日志根本不会告诉你上一行哪次赋值埋的雷。
