runtime.FuncForPC 是 Go 中获取函数名最可靠的方式，通过 runtime.Caller(0) 获取 PC 值后查符号表，返回完整签名如 "main.main"；需禁用内联、避免符号剥离，不可封装为通用工具函数。
runtime.FuncForPC 获取函数信息最可靠
Go 没有像 Python 的 inspect.currentframe().f_code.co_name 那样直接拿函数名的内置方式，但 runtime.FuncForPC 是标准库中唯一稳定、跨平台、不依赖调试信息的方案。它通过程序计数器（PC）反查运行时符号表，返回 *runtime.Func，再调用 Name() 得到完整函数签名（如 "main.main" 或 "myapp/handler.ServeHTTP"）。
关键点是：必须传入「当前栈帧的 PC 值」，而 runtime.Caller(0) 正好能拿到它——Caller(0) 返回的是调用它的那行代码的 PC，所以要写在目标函数内部，且不能被内联优化掉。
常见错误现象：FuncForPC 返回 nil，通常是因为传入了错误的 PC（比如用了 uintptr(0)、或从 goroutine 创建时捕获的 PC）、或函数被编译器内联（尤其小函数在 -O2 下默认内联）。
- 必须在目标函数体内调用
runtime.Caller(0)，不要封装成通用工具函数（否则Caller(0)指向的是工具函数自身） - 禁用内联：在函数上加
//go:noinline注释，例如：//go:noinline func getCurrentFuncName() string { pc, _, _, _ := runtime.Caller(0) f := runtime.FuncForPC(pc) if f == nil { return "unknown" } return f.Name() } -
f.Name()返回的是包路径+函数名，不含参数和返回值；若只要纯函数名（如"ServeHTTP"），需用strings.LastIndexByte截取最后一个'.'后的部分
为什么不能用 reflection 或 debug.PrintStack
反射（reflect）无法获取当前函数名，因为 Go 的 reflect 包设计上不暴露运行时调用栈信息；debug.PrintStack() 或 runtime.Stack() 输出的是字符串，需正则解析，既慢又不可靠（格式可能随 Go 版本变化，且在生产环境开启 stack trace 有性能开销）。
使用场景上，仅当调试、日志 trace ID 打点、或 panic 捕获时需要函数名才值得用 runtime.FuncForPC；高频调用（如每毫秒一次）应避免，因 FuncForPC 查表有微小开销（纳秒级，但累积起来明显）。
-
debug.PrintStack()会打印到os.Stderr，无法直接提取函数名，只能重定向 + 解析，不推荐 -
runtime.Stack(buf, false)返回字节切片，首行通常是goroutine 1 [running]:，第二行才是函数位置，但格式不稳定（如 Go 1.21 起对内联函数显示为inline /path/to/file.go:12） - 第三方包如
github.com/pkg/errors的errors.WithStack本质也是调用runtime.Stack，同样存在解析风险
在 defer 或匿名函数里怎么拿外层函数名
如果在 defer 或闭包里想获取「定义它的那个函数」的名字（而非 defer 执行时所在的函数），就不能用 Caller(0) —— 它指向的是 defer 语句所在行，即外层函数体内部，但 PC 值仍是外层函数的，所以其实仍可用。真正要注意的是：匿名函数本身没有名字，FuncForPC 返回的是类似 "main.main.func1" 这样的合成名。
常见错误是误以为 defer func() { ... }() 中的 ... 能直接访问外层函数名变量，结果发现没声明——必须显式捕获：
- 正确做法：在定义
defer时把函数名作为参数传入闭包，例如：func outer() { name := runtime.FuncForPC(reflect.ValueOf(outer).Pointer()).Name() defer func(n string) { log.Printf("exiting %s", n) }(name) } - 更简洁：直接在
defer前调用Caller(0)并保存结果，避免闭包里重复查表 - 注意：
reflect.ValueOf(fn).Pointer()只对导出函数或已知函数变量有效，对未导出函数或闭包无效，慎用
交叉编译和 CGO 环境下的兼容性
runtime.FuncForPC 在所有官方支持的平台（linux/amd64、darwin/arm64、windows/386 等）都可用，但前提是二进制包含调试符号。默认 go build 生成的可执行文件包含符号表，但若用了 -ldflags="-s -w"（剥离符号和调试信息），FuncForPC 将始终返回 nil。
CGO 环境下无额外问题，因为 runtime 包本身是纯 Go 实现，不依赖 C 栈帧；但若混用 C 函数回调 Go 闭包，且希望在 C 回调里获取 Go 函数名，则需确保回调是通过 export 函数触发，并在 Go 侧预留 PC 上下文。
- 生产构建时如需保留函数名，避免使用
-ldflags="-s"；-w（去掉 DWARF）不影响FuncForPC，但-s（去掉符号表）会彻底失效 - 交叉编译（如
GOOS=linux GOARCH=arm64 go build）行为一致，无需额外处理 - 在 App Engine 或某些容器环境里，若镜像基础层精简过度（删了
/proc或限制ptrace），一般也不影响，因为FuncForPC不依赖系统调用
真正容易被忽略的是内联和符号剥离——这两个开关一开，FuncForPC 就静默失败，连 error 都不报，只会返回空字符串或 "unknown"。上线前务必在目标环境验证一次输出。
