Go语言如何获取函数调用栈_Golang runtime.Caller信息提取-Golang-PHP中文网

结论：skip值应根据调用栈深度动态设置，runtime.caller(1)获取的是自身位置，封装日志中需用skip=2；需检查ok再调funcforpc，且避免高频使用以防性能损耗。

go语言如何获取函数调用栈_golang runtime.caller信息提取

直接说结论：用 runtime.Caller(skip) 获取调用位置，再配合 runtime.FuncForPC(pc) 提取函数名；但 skip 值极易设错，且每次调用都有真实性能开销，不能无脑塞进日志。

为什么 `runtime.Caller(1)` 经常返回错误的文件和行号

不是函数有问题，是 skip 的语义被误解了。runtime.Caller(1) 的 “1” 不是指“跳过当前函数”，而是“跳过从 runtime.Caller 这一行开始向上数的 1 层栈帧”。如果你把它封装在日志工具里，比如：

func LogInfo(msg string) {
    _, file, line, _ := runtime.Caller(1)
    fmt.Printf("[%s:%d] %s", file, line, msg)
}

那它拿到的其实是 LogInfo 自己这一行的位置，不是业务代码调用 LogInfo 的那一行。真正要定位到业务侧，得设 skip = 2 —— 跳过 LogInfo + runtime.Caller 自身这两层。

直接在业务函数里调用：用 runtime.Caller(1)
封装在 log.Info() 或自定义日志方法内：用 runtime.Caller(2)（标准库 log.Output 内部还会再跳一层，实际可能需 3）
在 defer func() { recover(); ... } 中捕获 panic：用 runtime.Caller(2)，因为 recover() 占一层，panic 触发点再上一层
设错的后果不是 panic，而是日志里显示的 file 和 line 指向封装层，排查时徒劳无功

如何安全提取调用者函数全名（避免 panic）

runtime.FuncForPC(pc) 返回 *runtime.Func，它的 Name() 方法虽做了 nil 判断，但前提是 pc != 0。而 runtime.Caller 在失败时返回 pc = 0，此时直接调 runtime.FuncForPC(0).Name() 会返回空字符串，不 panic，但结果不可靠。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

必须先检查 ok 返回值为 true，再用 pc
不要对同一个调用分三次调 runtime.Caller(2) 分别取 file、line、func name——开销翻倍
推荐统一提取：

func getCaller(skip int) (name, file string, line int) {
    pc, f, l, ok := runtime.Caller(skip)
    if !ok {
        return "", "", 0
    }
    fn := runtime.FuncForPC(pc)
    if fn == nil {
        return "", f, l
    }
    return fn.Name(), f, l
}