Golang中利用runtime.FuncForPC函数获取运行时函数信息与行号-Golang-PHP中文网

runtime.funcforpc 返回 nil 的根本原因是传入的 pc 值未指向函数入口或有效指令范围，可靠 pc 只能来自 runtime.caller(n) 或 runtime.frame.pc；内联优化、符号剥离（-ldflags="-s -w"）、cgo 环境等也会导致其失效。

golang中利用runtime.funcforpc函数获取运行时函数信息与行号

runtime.FuncForPC 为什么返回 nil？

多数人第一次用 runtime.FuncForPC 时，拿到的是 nil，不是函数名也不是行号。根本原因是：传入的程序计数器（PC）值必须指向函数入口或其有效指令范围，而直接用 uintptr(unsafe.Pointer(&someFunc)) 或随便取个地址（比如变量地址、栈指针）基本都无效。

真正能用的 PC 值，通常来自：

runtime.Caller(n) 返回的 PC —— 这是最可靠来源，它返回调用栈第 n 层的 PC
runtime.Frame.PC（比如从 runtime.Callers + runtime.CallersFrames 解析后）
不能用 reflect.ValueOf(fn).Pointer()，那只是函数值的底层指针，不等于可执行代码起始地址

如何正确获取当前函数名和行号？

想在函数内部打印自己名字和调用位置，别手动算 PC，直接用 runtime.Caller 配合 runtime.FuncForPC：

func debugInfo() {
    pc, file, line := runtime.Caller(0) // 0 表示当前函数帧
    fn := runtime.FuncForPC(pc)
    if fn != nil {
        fmt.Printf("func: %s, file: %s, line: %d\n", fn.Name(), file, line)
    }
}

注意：runtime.Caller(0) 返回的是 debugInfo 函数体内的 PC，fn.Name() 就是 "main.debugInfo"；而 file 和 line 是调用 runtime.Caller 这一行的位置 —— 它们来源不同，但组合起来才有意义。

常见误用：

用 runtime.Caller(1) 想“跳过自己”，结果 fn.Name() 变成上层函数名，但 file/line 还是 debugInfo 内部的位置 → 名称和行号错位
没判空就调 fn.Name()，panic：panic: runtime error: invalid memory address or nil pointer dereference

FuncForPC 在 panic 恢复栈中怎么用？

在 recover() 后想还原 panic 发生点的函数信息，不能只靠 runtime.Caller，因为 panic 可能发生在任意深度。正确做法是结合 runtime.Callers 和 runtime.CallersFrames：

Golang Uber Dig

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

下载

func recoverWithTrace() {
    if r := recover(); r != nil {
        var pcs [128]uintptr
        n := runtime.Callers(2, pcs[:]) // 跳过 recoverWithTrace 和 defer 匿名函数
        frames := runtime.CallersFrames(pcs[:n])
        for {
            frame, more := frames.Next()
            fmt.Printf("func: %s, file: %s:%d\n", frame.Function, frame.File, frame.Line)
            if !more {
                break
            }
        }
    }
}

这里关键点：