runtime.funcforpc不能获取函数地址，因其返回的是调试用符号信息而非可执行入口；它依赖pc值查表映射函数元数据，受内联优化、构建模式和平台差异影响，且pc可能指向stub或非函数体起始位置。
Go 语言中无法像 C 那样直接拿到函数的“入口地址”（即内存指针值），runtime.FuncForPC 返回的是运行时符号信息，不是可执行地址；它本质是用于调试和栈回溯的辅助工具，不是函数指针操作接口。
为什么 runtime.FuncForPC 不能获取“函数地址”？
Go 的函数值本身是闭包结构体（包含 code pointer + closure data），而 runtime.FuncForPC 接收的是程序计数器（PC）值——通常是某条指令的地址，比如 call 指令后的返回地址，或通过 uintptr(unsafe.Pointer(&fn)) 得到的近似值。但这个值：
- 不是标准定义的“函数入口”，Go 编译器可能做内联、跳转优化，实际入口可能被移除或重定向
- 在不同构建模式（如
-gcflags="-l"关闭内联）下结果不一致 - 跨平台（尤其是 ARM64）时，PC 值可能指向 stub 或 PLT 入口，而非原始函数体
-
Func.Entry()返回的是该函数在二进制中的符号起始偏移，不是运行时可调用地址
如何用 runtime.FuncForPC 获取函数名与源码位置？
典型用途是日志、panic 捕获、性能分析中还原调用栈。关键在于传入一个“合法且有意义”的 PC 值：
- 最稳妥方式：用
runtime.Caller(0)获取当前帧的 PC，再传给runtime.FuncForPC - 若想查某个函数自身：可用
uintptr(unsafe.Pointer(&myFunc))，但需确保myFunc未被内联（加//go:noinline注释） -
Func.Name()返回带包路径的完整名（如"main.handleRequest"），不是短名 -
Func.FileLine(pc)可定位到具体行号，但 pc 必须落在该函数代码范围内（不能传函数外的任意地址）
示例：
func myFunc() {}
//go:noinline
func getFuncInfo() {
pc := uintptr(unsafe.Pointer(&myFunc))
f := runtime.FuncForPC(pc)
if f != nil {
fmt.Println(f.Name()) // "main.myFunc"
fmt.Printf("%s:%d\n", f.FileLine(pc)) // 如 "main.go:12"
}
}
常见错误：传错 PC 值导致 FuncForPC 返回 nil
这是最常踩的坑——runtime.FuncForPC 对输入非常敏感，返回 nil 不报错，但后续调用会 panic：
- 传入 0、负数、或超出二进制 text 段范围的地址 → 返回
nil - 传入已内联函数的地址（即使加了
&fn）→ 实际没符号记录，返回nil - 在 goroutine 刚启动、栈尚未建立完整时调用 → PC 不稳定，结果不可靠
- 用
reflect.Value.Pointer()获取函数值地址？不行，Go 函数值不允许取地址，会 panic
安全做法永远优先用 runtime.Caller 获取 PC，而不是手动构造。
替代方案：需要“函数标识”时该用什么？
如果你真正想要的是函数唯一标识（比如注册回调、做类型区分），别依赖地址或名字字符串：
- 用函数值本身作 map key（
map[func()]string）——Go 允许函数类型作为 key，底层基于 runtime hash - 用
reflect.ValueOf(fn).Pointer()？不行，reflect.Value.Pointer()对 func 类型 panic；但reflect.ValueOf(fn).UnsafeAddr()也不支持 - 生成唯一 ID：结合
runtime.FuncForPC(runtime.Caller(0)).Name()+ 包名哈希，仅限调试场景 - 生产环境做路由或插件系统，应显式定义 interface 或 registry 结构，而非解析函数地址
函数地址在 Go 中不是一等公民，强行提取容易误用。真正需要符号信息时，FuncForPC 是唯一标准途径，但它只回答“这是哪个函数”，不回答“怎么跳过去”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
