runtime.FuncForPC 返回 nil 的根本原因是传入的 PC 值未指向函数入口或有效指令范围，可靠 PC 只能来自 runtime.Caller(n) 或 runtime.Frame.PC；内联优化、符号剥离（-ldflags="-s -w"）、CGO 环境等也会导致其失效。
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 这一行的位置 —— 它们来源不同，但组合起来才有意义。
立即学习“go语言免费学习笔记（深入）”；
常见误用：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
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：
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
}
}
}
}
这里关键点：
-
runtime.Callers(2, ...)的2是为了跳过当前函数和 defer wrapper，起点更接近 panic 点 -
frame.Function底层就是调用了runtime.FuncForPC(frame.PC)，但封装好了判空和符号解析 - 直接对
frame.PC再调一次runtime.FuncForPC是冗余的，且可能因内联优化导致函数名不可靠
内联函数会导致 FuncForPC 失效吗？
会，而且很隐蔽。Go 编译器默认开启内联（-gcflags="-l" 关闭），一旦函数被内联，它的代码就消失在调用方体内，runtime.FuncForPC 查不到独立函数符号，返回 nil 或返回外层函数名。
验证方式：
- 编译时加
go build -gcflags="-m=2"，看哪些函数被 inlined - 加
//go:noinline注释强制禁止内联，再测FuncForPC - 调试时发现
frame.Function总是显示调用方而非目标函数，大概率是内联所致
这不是 bug，是设计使然 —— 内联后没有独立函数实体，PC 值自然不属于某个函数符号表条目。
实际日志、监控或诊断工具里，如果依赖函数名做分类，得提前考虑内联影响；生产环境建议统一关闭内联（-gcflags="-l"）或用 runtime.Frame 而非裸 FuncForPC。
