go中打印当前函数调用栈应使用runtime.stack(buf, false)，需预分配足够缓冲区并用返回值n截取；runtime.caller(1)仅获取单层调用位置，适合轻量日志定位，二者不可混用。
如何在 Go 中打印当前函数调用栈
Go 提供了 runtime.Caller 和 runtime.Stack 两种主流方式获取调用栈，但它们用途不同：前者适合定位单层调用（比如记录日志时的文件/行号），后者适合完整捕获当前 goroutine 的栈帧。直接调用 runtime.Stack 是最简单粗暴的打印方式：
buf := make([]byte, 1024*8)
n := runtime.Stack(buf, false)
fmt.Printf("%s", buf[:n])
注意 false 表示只打印当前 goroutine；设为 true 会尝试打印所有 goroutine 的栈，但在生产环境极易卡死或 OOM，不建议使用。
为什么 runtime.Caller(0) 总是返回自身位置
runtime.Caller(n) 的参数 n 是“向上跳过几层调用”，0 指当前函数本身，1 才是调用者。常见错误是写成：
func log() {
_, file, line, _ := runtime.Caller(0) // 错！得到的是 log 函数自己的位置
fmt.Printf("%s:%d", file, line)
}
正确做法是传 1 或更高值，取决于你希望追溯到哪一层：
-
runtime.Caller(1)→ 直接调用log()的那行代码 -
runtime.Caller(2)→ 再上一层，比如某个 handler 或 test 函数
如果封装了日志工具，务必在内部把 n 设为至少 1，否则日志永远显示在工具函数里，失去调试意义。
panic 时自动打印完整调用栈的条件
Go 默认 panic 会打印调用栈，但前提是 panic 没被 recover 吞掉，且没被第三方库静默处理。某些中间件（如 gin 的 recovery()）会捕获 panic 并只输出摘要，导致栈丢失。
要确保看到完整栈，可手动触发 panic 并不 recover：
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
func debugPanic() {
panic("debug stack trace")
}
或者，在 recover 后显式打印：
if r := recover(); r != nil {
buf := make([]byte, 4096)
n := runtime.Stack(buf, false)
log.Printf("panic recovered: %v\n%s", r, buf[:n])
}
注意 runtime.Stack 返回的字节数可能超过缓冲区长度，必须用 n 截断，否则会 panic。
性能开销与生产环境慎用场景
runtime.Stack 是同步阻塞操作，底层会暂停当前 goroutine 并遍历栈帧，小栈（几十层）耗时约微秒级，但深栈（数百层）或高频调用时延迟明显上升。它还会分配堆内存（即使复用 buffer，runtime.Stack 内部仍需临时结构）。
以下情况应避免直接调用：
- 高频路径（如每请求都打栈）
- 延迟敏感服务（gRPC、实时推送）
- 资源受限环境（嵌入式、WASM）
替代方案：用 runtime.Caller(1) 获取调用点信息（文件+行号），开销低两个数量级；或仅在 error 构造时附加栈（如 fmt.Errorf("xxx: %w", errors.WithStack(err)) 配合第三方包）。
真正需要全栈的地方其实很少——多数时候你只需要知道「谁调用了这个函数」，而不是「整个 goroutine 的每一层调用」。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
