Go语言明确不支持尾递归优化，所有递归调用均产生新栈帧，易因栈溢出panic；改写为迭代时需将原终止条件拆分为入栈前过滤和出栈后校验两层，避免空指针或死循环。
Go 语言里没有尾递归优化——不是还没实现，是明确不支持，也不打算支持。
tailFactorial 这种写法看着像尾递归，但运行时和普通递归完全一样，栈帧照常增长，深度一高就 panic。
tail call optimization 在 Go 中根本不存在
- Go 官方编译器（gc）从设计上就不识别尾调用，
return f(x)、return f(x) + 0、return obj.Method()全都不触发任何栈复用 -
go tool compile -gcflags="-m"输出里永远不会有 “tail call optimized” 字样，只有can inline或escapes - gccgo 曾在极旧版本中对极简裸调用做过有限尝试，但不可靠、不跨平台、不维护，不能当真
为什么改写成迭代比等优化更实际
- 递归深度超 1000 层就可能触发栈扩容，超 5000 层极易 panic，错误信息通常是
runtime: goroutine stack exceeds 1000000000-byte limit - 每次递归调用都分配新栈帧，哪怕参数只是两个
int，也逃不过内存和调度开销 - 树遍历、JSON 解析、AST 处理这类场景，用
[]*Node+for循环替代，能精确控制容量、避免类型擦除、防止指针失效
容易被忽略的迁移细节：终止条件要拆两层
- 原递归里的
if node == nil { return }不能直接删掉或平移到循环末尾 - 必须拆成：
- 入栈前过滤：
if curr != nil { stack = append(stack, curr) } - 出栈后校验：
if curr == nil { continue }或直接跳过处理
- 入栈前过滤：
- 漏掉任一层，轻则空指针 panic，重则重复入栈、死循环、结果错乱
事情说清了就结束。最易忽略的是：把递归改迭代时，原终止条件往往需要拆解成“入栈过滤”+“处理前校验”两层，而不是一挪了事。
