go编译器不优化尾递归，tailfactorial等函数仍会栈溢出；应改用迭代+显式堆栈，预估容量、避免类型擦除、确保指针有效，并禁用goroutine模拟递归。
Go 里 tailFactorial 不会省栈，别信“尾递归就安全”
Go 编译器（gc）完全不识别尾递归形式，return tailFactorial(n-1, n*acc) 这种写法看着像尾调用，但实际仍会为每次调用分配新栈帧。哪怕参数只有两个 int，深度超 10000 就大概率 panic：runtime: goroutine stack exceeds 1000000000-byte limit。
- 真正能触发栈复用的场景在 Go 中不存在——连裸
return f()都不优化，更别说带运算或方法调用 - 本地跑
tailFactorial(5000, 1)可能没事，但上线后处理用户上传的嵌套 JSON（深度 8000+）直接 crash -
go tool compile -gcflags="-m" main.go能确认：所有递归调用都会显示can inline或escapes，但绝不会出现 “tail call optimized” 类字样
用 for + []*TreeNode 替代 DFS 递归最稳妥
树遍历、AST 解析、模板嵌套展开这类场景，优先把递归逻辑改写成迭代。核心不是“去掉递归”，而是把栈从系统内存移到堆上，由你显式控制容量和生命周期。
- 初始化切片时预估最大深度，比如已知树高 ≤ 2048，就写
stack := make([]*TreeNode, 0, 2048)，避免频繁扩容 - 别用
[]interface{}存节点指针——类型擦除带来额外 GC 压力，且每次取值都要类型断言 - 注意指针有效性：不要把局部变量地址（如循环内声明的
node）直接 append 进栈切片，应确保它指向 heap 分配的对象 - 示例中
inorderIterative的关键判断是curr != nil || len(stack) > 0，漏掉任一条件都会提前退出或死循环
别用 goroutine + channel 模拟“轻量递归”
有人试过用 go f() 启新 goroutine 等结果，以为能绕过栈限制。这反而更危险：每个 goroutine 默认栈至少 2KB，10 万次调用就是 200MB 内存，且无法回收直到 channel 被消费完毕。
- goroutine 调度开销远高于函数调用，深度递归本就慢，加一层调度只会更慢
- 若 channel 未被及时消费，goroutine 永久阻塞，内存泄漏+ goroutine 泄漏双杀
-
sync.WaitGroup在递归中嵌套使用极易漏Done()，导致Wait()永远不返回 - 并发 Fibonacci 示例看似炫技，但
n=40就生成上百万 goroutine，实际生产环境必须禁用
调试时用 runtime.Stack 打点比猜更可靠
上线前不确定递归深度是否安全？别靠经验估算，直接在入口打点看真实栈用量。
- 在递归函数开头加
buf := make([]byte, 1024); n := runtime.Stack(buf, false); fmt.Printf("stack usage: %d\n", n) - 注意
runtime.Stack返回的是当前 goroutine 的栈 dump 字节数，不是剩余空间；超过 8MB 就该警惕 - 结合压测数据看：同一请求下，输入长度翻倍，栈用量是否近似翻倍？若是，说明没逃过线性增长陷阱
- 日志里记录
len(stack)和当前处理层级（如 JSON path），出问题时能快速定位哪层开始失控
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
