runtime.Caller(1) 返回调用当前函数的上一层函数的文件名、行号和程序计数器（PC），是定位错误源头最常用的方式；skip=0 返回自身位置，skip=2 可用于多层封装场景，ok为false时需避免解包空值。
runtime.Caller 是 Go 中获取单层调用栈信息最轻量、最常用的方式，但它不是“打印堆栈”的万能函数——它只返回一层（文件、行号、PC），想看完整调用链得组合其他 API。
runtime.Caller(1) 返回的是谁？
它返回的是 调用当前函数的上一层函数 的位置信息，不是当前函数自身。比如你在 logError 里写 runtime.Caller(1)，拿到的是调用 logError 那行代码的文件和行号，这对定位错误源头非常关键。
- skip = 0 → 返回
runtime.Caller自身所在栈帧（几乎没用） - skip = 1 → 返回调用者的文件名、行号、PC（最常用）
- skip = 2 → 再往上跳一层，适合封装多层日志/错误包装函数
- 如果
ok == false，说明栈太浅或 goroutine 已结束，别直接解包file或line
如何从 PC 拿到函数名？必须用 runtime.FuncForPC
runtime.Caller 返回的 pc 是程序计数器地址，不能直接当字符串用。要转成函数名，必须传给 runtime.FuncForPC(pc)，再调用其 .Name() 方法：
pc, file, line, ok := runtime.Caller(1)
if !ok {
return "unknown"
}
fn := runtime.FuncForPC(pc)
if fn == nil {
return "unknown"
}
return fn.Name() // 返回类似 "main.test" 或 "github.com/user/pkg.(*Client).Do"
- 注意：
runtime.FuncForPC可能返回nil（尤其在内联优化开启时或 CGO 环境下） - 返回的函数名带完整包路径，如需纯函数名，得用
strings.LastIndex截取最后一段 - 不要在 hot path（高频调用路径）反复调用它，有性能开销
打印完整堆栈该用 debug.Stack 还是 runtime.Stack？
两者都可，但语义和用途不同：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
-
debug.Stack()：返回当前 goroutine 的完整堆栈（含函数名、文件、行号），适合调试和 panic 日志，无需预分配 buffer -
runtime.Stack(buf, false)：需要自己提供[]byte缓冲区；false表示只当前 goroutine，true表示所有 goroutine（慎用，可能卡住） - 如果只是记录错误上下文，
debug.Stack()更简洁安全；若做监控采集或需要控制内存分配，选runtime.Stack - 注意：
debug.Stack()在某些极端情况（如栈溢出）可能失败，而runtime.Stack更底层、更稳定
封装错误时 runtime.Caller 的 skip 值容易错
你在封装错误（比如 WrapError）时，runtime.Caller(1) 拿到的是封装函数自己的调用点，不是原始错误发生处。真正想捕获“错误诞生地”，应设为 runtime.Caller(2) 或更高 —— 前提是你清楚封装层数。
- 例如：
db.Query()→wrapErr()→logError()，你想记db.Query那行，就得在logError里用runtime.Caller(2) - 但硬编码
skip=2不健壮，推荐用runtime.Callers+runtime.CallersFrames遍历，跳过已知的封装函数名（如包含"WrapError"或"logError"） - 第三方库如
pkg/errors就是这么做的：调用runtime.Callers(2, ...)，自动跳过自身构造逻辑
真正难的不是调用哪个函数，而是理解 skip 的语义在每一层封装中如何累积 —— 这一点，连很多老手都会在嵌套日志中间接丢掉关键堆栈帧。
