runtime.Caller(1)开销远超直觉，需完整调用栈遍历，单次耗时80–120ns；常见错误包括日志吞吐骤降、pprof显示runtime.callers占比高、GC压力上升及skip设错导致定位偏差。
runtime.Caller(1) 的实际开销远超直觉
它不是简单的指针读取，而是触发一次完整的调用栈遍历：从当前 goroutine 的栈顶开始，逐帧解析返回地址、定位符号表、匹配函数元数据。哪怕只取 1 层，底层仍需构造完整帧结构并校验有效性。在压测中，单次 runtime.Caller(1) 平均耗时约 80–120ns（Go 1.22+，x86_64），看似微小，但日志每条都打一次，QPS 10k 的服务每秒就多出 1ms 以上纯堆栈开销。
常见错误现象包括：
- 日志吞吐量骤降，
log.Printf耗时从50ns涨到200ns+ - pprof CPU profile 显示
runtime.callers和runtime.funcs.find占比异常高 - GC 压力上升——每次调用都分配临时字符串（
file）和反射对象（FuncForPC）
skip 参数设错会导致文件/行号完全对不上
skip 不是“跳过几层业务代码”，而是跳过 runtime 包内部的封装层数。比如你在日志封装函数里写 runtime.Caller(1)，拿到的是封装函数自己的位置；要拿到真正调用日志的地方，得设成 2 或 3，具体取决于中间是否经过 fmt.Sprintf、log.Output 等标准库转发。
典型场景与推荐 skip 值：
- 直接在业务函数里调用：
runtime.Caller(1) - 封装在
Log.Info(...)方法内：runtime.Caller(2)（跳过 Log.Info 自身 + runtime.CallersFrames 内部调用） - 在 defer + recover 中捕获 panic 后取原始错误位置：
runtime.Caller(2)（recover 函数本身占 1 层，panic 触发点再上 1 层）
设错的后果不是报错，而是日志里显示的 file 和 line 指向封装层，排查时直接走偏。
别重复调用 Caller 获取 file/line/funcName
同一个 runtime.Caller(skip) 调用就能同时拿到 pc、file、line。但很多项目拆成三个独立函数，比如 beego 的 utils.FILE() 和 utils.LINE() 各自调一次 runtime.Caller(1)，等于开销翻倍。
正确做法是复用一次调用结果：
func getCallerInfo(skip int) (string, string, int) {
pc, file, line, ok := runtime.Caller(skip)
if !ok {
return "", "", 0
}
name := runtime.FuncForPC(pc).Name()
return name, file, line
}
注意：runtime.FuncForPC(pc) 也有开销，如果只要文件和行号，就别调它；如果还要函数名，确保 pc 有效（pc != 0）再查，避免 panic。
生产环境必须做条件控制
堆栈信息对线上故障定位极有用，但代价是确定的。不能靠“少打几条日志”来缓解，而应从编译期或配置层开关。
可行方案：
- 用 build tag 控制：开发用
//go:build debug，生产编译加-tags=prod，日志组件里用if buildtag.Debug { ... runtime.Caller(...) ... } - 运行时开关：日志初始化时传入
WithCaller(true/false)，内部缓存 flag，caller 相关逻辑全走 if 分支，避免无谓调用 - 分级策略：ERROR 级别强制采集，INFO/WARN 只在 debug 模式下采集
最易被忽略的一点：即使关了 caller，runtime.FuncForPC 如果误用（比如传入零值 pc），仍会 panic。所有对 pc 的后续使用，必须先检查 ok 返回值，不能只依赖 skip 推断。
