runtime.Caller返回(pc uintptr, file string, line int, ok bool)，depth是固定偏移量而非深度上限：depth=0指向自身，depth=1指向直接调用者，depth=2跳过一层封装，超出栈深时ok=false。
runtime.Caller 返回什么，参数 depth 怎么理解
runtime.Caller 不返回完整调用栈，只返回**某一层**的调用信息，类型是 (pc uintptr, file string, line int, ok bool)。关键在 depth 参数：它表示从当前函数往回数第几层 —— depth = 0 是 runtime.Caller 自身，depth = 1 是它的直接调用者，以此类推。
常见误用是传 0 或硬编码 2，结果拿到的是封装函数或日志工具内部的文件/行号，而不是业务代码位置。
- 想定位「谁调用了当前函数」→ 用
depth = 1 - 想跳过中间一层封装（比如自定义 logger）→ 用
depth = 2，但要确保调用链稳定 - 不确定深度时，先打印多层试试：
for i := 0; i
获取函数名要用 runtime.FuncForPC，但要注意 pc 偏移
runtime.Caller 返回的 pc 是指令指针，不是函数入口地址。直接传给 runtime.FuncForPC(pc) 可能返回 nil，因为 pc 指向的是调用点所在行对应的机器指令，不一定落在目标函数的代码段内。
安全做法是减去 1 再传入：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
pc, _, _, _ := runtime.Caller(1)
f := runtime.FuncForPC(pc - 1)
if f != nil {
fmt.Println(f.Name()) // 如 "main.main" 或 "http.(*ServeMux).ServeHTTP"
}- 不减 1：某些 Go 版本（尤其是 1.20+）下
FuncForPC更严格，容易返回nil - 减 1 是保守做法，覆盖绝大多数情况；极端情况下（如内联函数末尾调用），可能仍不准
- 如果只要文件和行号，不用函数名，就完全不需要
FuncForPC
在 defer / panic 场景中获取调用者要格外小心
在 defer 函数里调用 runtime.Caller(1)，拿到的可能是 defer 注册处的调用者，而不是 defer 实际执行时的上下文。panic 时同理 —— recover 中调用 Caller，depth 计算起点是 recover 所在函数，不是 panic 发生点。
- 想记录 panic 位置？别依赖
runtime.Caller，改用debug.PrintStack()或runtime.Stack(buf, false) - 想在 defer 日志里打“谁调用了这个函数”？确保
defer是在目标函数开头注册的，且没被其他 wrapper 包裹 - 需要精确到 panic 行号又不想用 Stack？可在 panic 前手动存一次
runtime.Caller(1)到闭包变量中
性能开销不小，别在热路径频繁调用
runtime.Caller 需要解析程序计数器、查找符号表、读取源码映射，实测比普通函数调用慢 1–2 个数量级。在高频循环、HTTP handler 主逻辑、或每秒万级请求的场景中，它会成为明显瓶颈。
- 日志级别为 Debug/Trace 时才启用调用栈采集，生产环境默认关闭
- 避免在 for 循环内调用；如需多次，提前在函数入口调一次并缓存
file:line - 注意
runtime.Caller在 CGO 调用前后行为可能异常，尤其涉及 C 函数回调 Go 的场景
真正需要调用栈的地方不多，多数时候 file:line 就够用；函数名和完整栈是奢侈功能，得权衡代价。
