递归函数应根据是否需修改原始数据选择传指针或值：需修改（如树标记、dfs染色、回溯复原）必须传指针，只读小结构体可传值；切片append需传*[]t，map元素修改可直接传，但赋新值无效；defer操作指针共享状态易出错，应避免或拷贝当前值。
递归函数里传指针还是值？看这个变量会不会被修改
Go 的递归函数如果操作的是结构体或大对象，传值会触发完整拷贝，栈空间消耗陡增。但更关键的是：是否需要在递归中修改原始数据。比如树节点遍历+打标记、图的 DFS 染色、回溯时复原状态——这些都必须传 <em>TreeNode</em>、Graph 等指针类型，否则下层递归改的只是副本。
- 传值（
Node）：安全但低效，适合只读遍历且结构体小（如type Point struct{ X, Y int }） - 传指针（
*Node）：省空间、可写入，但要注意 nil 检查，尤其在叶子节点递归终止时容易 panicnil pointer dereference - 切片虽是引用类型，但底层数组可能被扩容复制，若需在递归中追加并保留结果，传
*[]int更稳妥（比如收集所有路径）
栈溢出不是因为递归太深，而是因为每次调用占的栈太多
Go runtime 默认栈初始大小是 2KB，按需增长，但频繁分配大栈帧仍会快速触顶。典型陷阱是：在递归函数里声明大数组、大结构体变量，或闭包捕获了大量外部变量。
- 避免在递归函数体内定义
buf [8192]byte这类大栈变量；改用make([]byte, 8192)分配到堆上 - 不要让递归函数直接闭包捕获整个大结构体，可提前解构出必要字段传参
- 对深度不确定的递归（如解析嵌套 JSON），优先考虑用显式栈（
[]*Node）+ for 循环替代，完全避开栈限制
map 和 slice 在递归中怎么传才不会“丢了修改”
Go 的 map 和 slice 是引用类型，但它们的头信息（len/cap/ptr）是值传递的。这意味着：
- 修改 map 元素（
m[k] = v）或 slice 元素（s[i] = x）不需要指针，原 map/slice 会反映变更 - 但对 slice 做
append可能导致底层数组扩容，新 slice 头指向新地址，原变量不变——所以如果递归中不断append并期望父层看到结果，必须传*[]T - 同理，给 map 赋新值（
m = make(map[K]V)）只改本地变量，不影响外层；要清空 map 应用for k := range m { delete(m, k) }，而不是重赋值
为什么 defer + 指针递归容易引发意料外的副作用
defer 在函数返回前执行，而递归中每层都有自己的 defer 队列。如果 defer 里操作的是指针指向的共享状态（比如计数器 *int 或全局缓存），顺序和时机极易混乱。
立即学习“go语言免费学习笔记（深入）”；
- 示例：递归下降解析时，在每层 defer 中
dec(*depth)，但 depth 是同一指针，实际执行顺序是“最深一层先 dec”，可能提前减到负数 - 更安全的做法是 defer 里只做资源释放（如 close(file)）、日志记录（不含共享状态变更），或用局部变量记录本层状态再 defer 操作
- 若必须 defer 修改共享状态，先拷贝当前值（
cur := <em>shared; defer func(){ </em>shared = cur }()），确保恢复逻辑可控
递归中指针真正的复杂点不在语法，而在你是否清楚每个变量的生命周期归属——栈帧、堆内存、逃逸分析结果，三者混在一起时，一个没检查的 nil、一次没注意的 append、一个没想清的 defer，就足以让行为偏离预期。
