树节点必须用指针而非值类型，因值类型会导致无限递归复制和编译错误；*TreeNode合法且只存地址，但需注意nil指针panic、显式初始化、遍历时判空及内存性能影响。
为什么树节点必须用指针而不能用值类型
Go 中结构体默认按值传递，如果 TreeNode 定义为值类型，每次赋值或传参都会复制整个结构体；更关键的是，子节点字段（如 Left、Right）若也存值类型，就会触发无限嵌套复制——编译器直接报错 invalid recursive type TreeNode。所以必须用指针：*TreeNode 是合法的，它只存地址，不引发递归定义。
常见错误写法：
type TreeNode struct {
Val int
Left TreeNode // ❌ 编译失败：recursive type
Right TreeNode
}
正确写法：
type TreeNode struct {
Val int
Left *TreeNode // ✅ 指针可指向自身类型
Right *TreeNode
}
如何安全地初始化和连接树节点
直接对 nil 指针解引用会 panic，所以新建节点后必须显式分配内存。常见误区是以为 var n *TreeNode 就能直接用 n.Left = &TreeNode{...}——其实 n 还是 nil，n.Left 会触发 panic。
立即学习“go语言免费学习笔记（深入）”；
- 用
&TreeNode{Val: 1}或new(TreeNode)创建非 nil 指针 - 连接子节点前，确保父节点指针已初始化（不是 nil）
- 批量建树时推荐用辅助函数封装，避免重复判空
示例：
root := &TreeNode{Val: 1}
root.Left = &TreeNode{Val: 2} // ✅ 安全
root.Right = &TreeNode{Val: 3} // ✅ 安全
// 错误示范（未初始化 root 就操作）
var root *TreeNode
root.Left = &TreeNode{Val: 2} // ❌ panic: assignment to entry in nil map / invalid memory address
遍历时如何避免 nil 指针 panic
几乎所有树操作（DFS、BFS、求深度、序列化）都需频繁访问 node.Left 和 node.Right。只要某一层节点为 nil，后续解引用就崩溃。最稳妥的方式是在每次访问子节点前做显式判断。
- 递归入口处加
if node == nil { return } - 迭代（如栈/队列）中出队/出栈后立即判空，再取子节点
- 不要依赖“树一定完整”——生产环境输入不可信
典型 DFS 模板：
func traverse(node *TreeNode) {
if node == nil { // ⚠️ 必须第一行检查
return
}
fmt.Println(node.Val)
traverse(node.Left) // 此时 node.Left 可能为 nil，但下层会拦截
traverse(node.Right)
}
指针带来的内存与性能隐含影响
用指针建树确实灵活，但也带来两个容易被忽略的实际问题：
-
==比较的是地址而非内容：两个相同结构的*TreeNode指针默认不相等，需手写 DeepEqual 逻辑 - GC 压力略高：每个节点都是独立堆分配对象，小树不明显，但百万级节点时，指针间接寻址 + 分散内存布局会影响缓存局部性
- 无法直接用
sync.Pool复用节点——因字段常含业务数据，清空成本可能高于新建
如果追求极致性能且树形态固定（如完全二叉树），可考虑用 slice 模拟堆式存储（索引算左右子），但这就脱离了“指针树”的设计初衷。
真正难的不是写出能跑的指针树，而是记住：每个 * 都意味着一次潜在的 nil、一次堆分配、一次间接寻址——这些在调试和压测时才会浮出水面。
