Go语言不支持尾调用优化（TCO），所有递归调用均生成新栈帧，无法通过尾递归降低栈空间；实际热路径优化应手动转为迭代、启用PGO、避免热路径分配对象。
Go 语言没有尾调用优化（TCO），所谓“热路径尾调用优化”是误解——编译器不会把 return f(x) 编译成跳转，而是照常压栈。
为什么 Go 的尾递归根本不是尾调用
Go 官方编译器（gc）截至 1.22 仍不支持 TCO，且无计划加入。所有递归调用，无论是否写成尾形式，都会生成新的栈帧：
-
FibTail(n-1, b, a+b)和Fib(n-1) + Fib(n-2)在汇编层面都调用CALL runtime.morestack_noctxt（必要时扩容栈），栈深度一样 - 用
go tool compile -S查看汇编，会发现两者都有CALL指令，而非JMP或RET后跳转 - 加
//go:noinline只影响内联，对调用方式毫无作用；@tailrec是 Scala/Kotlin 语法，Go 编译器直接报错
真正在热路径上能做的三件事
与其纠结“尾调用”，不如聚焦实际可落地的热路径优化手段：
-
手动展开为迭代：把递归状态（如
n, a, b）转为局部变量，用for循环驱动。这是唯一能将栈空间从 O(n) 降到 O(1) 的方法 -
启用 PGO（Profile-Guided Optimization）：对真实流量采集 profile（如
profile.pb），再用go build -pgo=profile.pb构建。PGO 能让编译器把高频执行的递归入口/出口路径做激进内联，减少 call/ret 开销 -
避免在热路径分配新对象：比如递归解析 JSON 时，不要每层都
json.RawMessage拷贝，改用切片偏移 + 共享底层数组；否则 GC 压力会掩盖任何调用优化收益
汇编验证：一眼识别有没有 TCO
用下面命令对比普通递归和“尾递归”写法的汇编输出：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
go tool compile -S -l -m=2 main.go | grep -A5 -B5 "CALL.*Fib"
你会看到：
- 两版函数都含
CALL main.FibTail或CALL main.Fib - 都没有
JMP main.FibTail这类跳转指令（那是 TCO 的标志） - 若某次编译意外出现
JMP，大概率是内联后被优化掉了——但这是内联（inlining）功劳，不是 TCO
最容易被忽略的点：热路径里 defer 不是零成本
Go 1.22 虽标榜 “zero-cost defer”，但仅针对无 panic 场景下的静态 defer。若递归函数里写了 defer func() { ... }()，每次调用仍需写入 defer 链表、维护指针，热路径下开销可观。实测在百万级调用中，去掉 defer 可降低约 8% CPU 时间——别让它混进你本想优化的热路径里。
