runtime.FuncForPC 需传入正确的返回地址或指令指针偏移量，最稳妥方式是用 runtime.Callers 获取调用栈 PC 值；直接传 &someFunc 或手写地址会失败，内联、CGO、符号剥离等场景下 FuncForPC 可能返回 nil。
runtime.FuncForPC 能拿到函数名，但必须传对 PC 值
直接调用 runtime.FuncForPC 时传错参数是常见错误——它不接受任意地址，而要求是「返回地址」或「指令指针偏移量」。最稳妥的方式是用 runtime.Callers 先获取调用栈帧，再取其中某一级的 PC 值。
-
runtime.Callers(1, pcs)的第一个参数是跳过几层调用：传1表示跳过当前函数本身，拿到的是调用方的 PC；传0会包含当前函数，但可能因内联优化失效 - PC 值必须来自
uintptr切片，不能手写数字或用&someFunc—— Go 函数值不是可寻址的代码地址 - 如果
runtime.FuncForPC(pc)返回nil，说明该 PC 不在已加载的函数范围内（比如指向 runtime 内部或未导出符号）
获取当前函数名的可靠写法
别依赖 reflect 或 debug.PrintStack 解析字符串，它们不稳定且开销大。下面这段是生产环境验证过的最小可行方案：
func getCurrentFuncName() string {
pc := make([]uintptr, 1)
n := runtime.Callers(1, pc[:]) // 跳过 getCurrentFuncName 自身
if n == 0 {
return "unknown"
}
f := runtime.FuncForPC(pc[0])
if f == nil {
return "unknown"
}
return f.Name()
}
注意：runtime.Callers 返回的是调用栈长度，不是错误码；切片长度必须 ≥1，否则 pc[:] 会 panic。
为什么不能用 runtime.Caller(0) 直接获取？
runtime.Caller(0) 确实更简洁，但它返回的是 file:line 和 pc，而它的 pc 指向的是「调用指令的下一条指令」，不是函数入口。多数情况下 FuncForPC 仍能匹配成功，但以下情况会失败：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 函数被编译器内联（尤其是小函数、无逃逸的函数），此时
pc可能落在外层函数体内 - 使用
//go:noinline可强制不内联，但仅限于你控制的函数；第三方库函数无法干预 - CGO 或汇编函数没有符号信息，
FuncForPC返回nil
实际使用中容易忽略的兼容性问题
函数名格式取决于构建方式和 Go 版本：
- 非导出函数（如
main.init或main.(*T).method）名字里含包路径和接收者类型，不是简单标识符 - Go 1.20+ 对闭包函数名做了标准化，形如
main.main.func1，但旧版本可能是main.main·1 - 交叉编译（如 darwin/amd64 → linux/arm64）时，符号表可能缺失，
FuncForPC更容易返回nil - 启用
-ldflags="-s -w"会剥离符号表，所有FuncForPC调用都失效
线上服务若需稳定获取函数名，建议只用于 debug 日志且带 fallback，不要用于逻辑分支判断。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
