runtime.caller(1)仅返回pc/file/line，需配合runtime.funcforpc(pc-1).name()获取函数名，skip值需根据调用栈深度调整，避免热路径频繁调用以减少性能开销。
runtime.Caller(1) 拿不到函数名，必须配 runtime.FuncForPC
直接调用 runtime.Caller(1) 只返回 pc、file、line 三个值，pc 是程序计数器地址，不是字符串。想得到类似 "main.doRequest" 或 "github.com/user/pkg.(*Client).Do" 这样的函数名，必须用 runtime.FuncForPC 转换。
常见错误是直接打印 pc 值，或漏判 runtime.FuncForPC(pc) 返回 nil：
-
runtime.FuncForPC(pc)在内联优化开启、CGO 环境、或 Go 1.20+ 严格模式下容易返回nil - 安全写法是先减 1：
runtime.FuncForPC(pc - 1)，覆盖绝大多数情况 - 拿到
Func对象后，再调.Name()才能得到完整函数签名 - 如只需纯函数名（不含包路径），用
strings.LastIndex(f.Name(), ".")截取最后一段
skip=1 不一定指向业务代码，封装层会干扰定位
你在日志封装函数里写 runtime.Caller(1)，拿到的是封装函数自己那行的 file 和 line，不是业务方调用 Log.Info() 的位置。这会导致排查时跳转到日志库内部，完全走偏。
典型 skip 值参考：
- 裸调用（无封装）：用
runtime.Caller(1) - 封装在
Log.Info()方法中：用runtime.Caller(2)（跳过 Log.Info + 标准库log.Output） - 在
defer + recover中捕获 panic：用runtime.Caller(2)（recover 占 1 层，panic 触发点再上 1 层） - 不确定深度时，先循环试
for i := 0; i ，看哪一层对应业务文件
性能开销比想象中大，别在热路径反复调用
单次 runtime.Caller(1) 平均耗时 80–120ns，看似微小，但高频场景下代价明显：
- QPS 10k 的 HTTP handler 每秒多出 1ms+ 纯堆栈开销
- pprof 显示
runtime.callers或runtime.funcs.find占比异常高 - GC 压力上升——每次调用都分配
file字符串和Func对象 - 别拆成三次调用：比如
utils.FILE()、utils.LINE()、utils.FUNC()各自调一次runtime.Caller(1)，开销直接翻三倍
panic 或 defer 场景下 Caller 定位容易失效
在 defer 函数里调 runtime.Caller(1)，拿到的是 defer 注册处的调用者，不是 defer 实际执行时的上下文；recover 中调用 Caller，depth 起点是 recover 函数本身，不是 panic 发生点。
更可靠的做法：
- 记录 panic 位置，优先用
debug.PrintStack()或runtime.Stack(buf, false) - 若坚持用
Caller，在 panic 前手动存一次runtime.Caller(1)到闭包变量中 - 在
defer日志中打“谁调用了本函数”，确保defer是在目标函数开头注册的，且没被其他 wrapper 包裹
真正难的不是调用方式，而是 skip 值怎么选、pc 怎么转函数名、以及什么时候不该用它——这些细节错一点，日志就指向错误文件，排查时间翻倍。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
