runtime.Caller 返回的是指定跳过帧数的调用者信息，传 0 得到自身位置，传 1 才得到调用当前函数的上一层代码的文件名与行号，这是定位错误源头的标准做法。
runtime.Caller 为什么返回的行号总是当前函数的？
因为 runtime.Caller 获取的是调用栈中指定深度的帧信息，传 0 就是它自己所在的位置。想拿到「谁调用了我」，得传 1 —— 表示上一层调用者。但要注意：如果中间有内联函数、编译器优化（如 -gcflags="-l" 关闭内联）或中间包做了封装（比如日志 wrapper），深度可能不是简单的 +1。
常见错误现象：runtime.Caller(0) 返回的是日志封装函数自己的位置，不是业务代码那行。
- 调试时先打
runtime.Caller(1)看是否符合预期；不行就试2、3 - 避免在 defer 中直接用
runtime.Caller(1)—— defer 执行时调用栈已展开，深度可能偏移 - Go 1.19+ 开始，
go build -gcflags="-l"可禁用内联，让调用栈更“诚实”，适合调试阶段使用
怎么安全地提取调用者的函数名和文件行号？
runtime.Caller 返回三个值：pc（程序计数器）、file、line，但函数名不在其中；得用 runtime.FuncForPC 查 pc 对应的函数对象，再调用 .Name()。这个过程可能返回 nil（比如 pc 指向 runtime 内部或被内联掉），必须判空。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func getCallerInfo() (string, string, int) {
pc, file, line, ok := runtime.Caller(1)
if !ok {
return "unknown", "unknown", 0
}
fn := runtime.FuncForPC(pc)
if fn == nil {
return "unknown", file, line
}
return fn.Name(), file, line
}
-
fn.Name()返回完整包路径前缀的函数名，如"main.main"或"github.com/user/pkg.(*T).Method" - 若只需简单函数名（去掉包名），可用
strings.LastIndex截取"."后部分，但注意方法名含"."的边界情况 - Windows 下
file路径含反斜杠，打印时建议用filepath.Base(file)提取文件名
性能敏感场景下要不要避免用 runtime.Caller？
要。每次调用 runtime.Caller 需遍历 goroutine 栈帧，开销比普通函数调用高 1–2 个数量级。压测中频繁打日志 + Caller 会导致 QPS 明显下降。
立即学习“go语言免费学习笔记（深入）”；
- 生产环境日志级别为
Info或更低时，建议关掉 Caller 信息（通过日志库配置，如 zap 的DisableCaller()） - 只在
Error或Debug级别开启，且最好配合条件判断（例如仅当 error != nil 时才采集） - 不要在 hot path（如循环体、HTTP handler 内部高频逻辑）里无条件调用
runtime.Caller - 替代方案：手动传
caller = fmt.Sprintf("%s:%d", filepath.Base(file), line)（需调用方配合，但零运行时开销）
第三方日志库（zap / logrus）里 Caller 是怎么工作的？
它们底层也是调 runtime.Caller，但做了封装和缓存优化。比如 zap 默认关闭 Caller，启用后默认查深度 1，可通过 zap.AddCallerSkip(n) 调整——这正是为了跳过日志封装层（如 logger.Info() 内部的转发函数）。
- logrus 用
logrus.SetReportCaller(true)，但默认深度是 2，常导致显示错位；建议搭配logrus.SetCallerPrettyfier自定义格式 - zap 的
With(zap.String("caller", ...))不会自动触发 Caller 采集，必须用zap.AddCaller()显式开启 - 所有库的 Caller 功能都受
GOFLAGS="-gcflags=all=-l"影响，CI 构建时若没加该 flag，本地调试看到的行号可能和线上不一致
