runtime.Caller 开销为80–200 ns，栈深超20层或符号未预加载时可达1–2 μs；Caller(0) 返回自身函数名，需用 Caller(1) 或 Callers+FuncForPC 跳过封装层获取真实调用方信息。
runtime.Caller 的基础开销有多大
调用 runtime.Caller 本身不是零成本操作。它需要遍历当前 goroutine 的栈帧、解析程序计数器（PC）、查找符号表以还原函数名和文件行号——这些步骤在 Go 1.20+ 中虽经优化，但仍是纳秒级到微秒级的开销，具体取决于栈深度和 symbol table 加载状态。
- 每次调用
runtime.Caller(0)在典型服务中平均耗时约 80–200 ns（实测 AMD EPYC + Go 1.22） - 若栈深超过 20 层，或符号未被预加载（如 CGO 混合场景），可能飙升至 1–2 μs
- 开销主要来自
runtime.findfunc和runtime.funcname的字符串拷贝与解码
这不是“不能用”，而是“别在 hot path 里裸调”。
为什么 Caller(0) 获取不到你期望的函数名
runtime.Caller(0) 返回的是调用它的那一行所在的函数，不是“上层业务函数”。如果你封装了一个日志辅助函数 logWithTrace()，并在其中调用 runtime.Caller(0)，拿到的就是 logWithTrace 自己的函数名和行号，而非调用 logWithTrace 的那个业务函数。
- 正确做法是传入偏移量：
runtime.Caller(1)指向直接调用者，runtime.Caller(2)再往上一层 - 偏移量写死易出错：内联（inlining）可能让编译器跳过某层函数，导致偏移错位；go test -gcflags="-l" 可禁用内联用于调试，但生产环境不可控
- 更稳妥的方式是结合
runtime.Callers+runtime.FuncForPC手动过滤，避开内联干扰（见下节）
如何安全获取真实调用方的函数名与行号
最常用且相对健壮的做法是：先用 runtime.Callers 获取一连串 PC，再逐个用 runtime.FuncForPC 解析，跳过标准库和日志封装函数。
pc := make([]uintptr, 32)
n := runtime.Callers(2, pc[:]) // 跳过本函数 + 上层封装，从 caller 开始采
for i := 0; i < n; i++ {
f := runtime.FuncForPC(pc[i])
if f == nil {
continue
}
name := f.Name()
// 过滤掉 vendor、runtime、log 等无关函数名
if strings.HasPrefix(name, "runtime.") || strings.Contains(name, "/vendor/") {
continue
}
file, line := f.FileLine(pc[i])
fmt.Printf("called from %s:%d (%s)\n", file, line, name)
break
}-
runtime.Callers(2, ...)是关键：2 表示跳过当前函数和它的直接调用者（即封装层） -
runtime.FuncForPC比runtime.Caller更底层，不受内联影响，但需确保 PC 有效（否则返回 nil） - 注意：
runtime.Callers返回的是调用栈快照，不保证 100% 准确（goroutine 抢占可能中断栈扫描），但在绝大多数日志/panic 场景下足够可靠
性能敏感场景下的替代方案
如果代码路径每秒执行数万次，且必须带 trace 信息，runtime.Caller 类操作就是瓶颈。此时应放弃动态获取，改用静态标注：
- 在关键入口（如 HTTP handler、RPC 方法）手动记录
funcName = runtime.FuncForPC(reflect.ValueOf(handler).Pointer()).Name()，只做一次，复用到整个请求生命周期 - 使用编译期注入：借助
//go:generate或 eBPF 工具链，在构建时把函数名写入常量或 map - 日志库如
zerolog默认不采栈，zap的WithCaller(true)默认只对Debug级别启用，且可配置 skip frames 数量——这些控制点比自己裸调Caller更可控
真正难处理的不是“怎么取”，而是“什么时候不该取”。很多 panic 日志里看到的 30% CPU 耗在 runtime.copystack，追根溯源往往是某处日志每毫秒都调了 runtime.Caller(1)。
