runtime.caller 返回的是调用当前函数的上一级调用者信息，不是当前函数自身；例如在 logerror 中调用 runtime.caller(1)，获取的是调用 logerror 那行代码的文件和行号，用于精准定位错误源头。
runtime.Caller 返回的是谁的调用信息？
它返回的是 runtime.Caller 这一行代码所在栈帧的**上一级调用者**信息，不是当前函数本身。很多人误以为它能直接拿到当前函数名或位置，结果拿到的是调用该函数的地方——比如你在 log.Debug 里调用 runtime.Caller(0)，得到的是调用 log.Debug 那行代码的位置。
所以要获取「当前函数」的文件和行号，得传参 1（跳过 runtime.Caller 自身），而不是 0。
-
runtime.Caller(0)→ 获取runtime.Caller所在行（即你写这行代码的位置） -
runtime.Caller(1)→ 获取调用当前函数的那一行（最常用） -
runtime.Caller(2)→ 再往上一层，依此类推
如何安全提取文件名与行号？
runtime.Caller 返回 (pc uintptr, file string, line int, ok bool)，ok 为 false 表示栈帧不可达（比如内联优化、CGO 调用、或 goroutine 刚启动还没执行到有效代码）。不检查 ok 直接用 file 或 line 可能导致 panic 或空字符串。
典型安全写法：
pc, file, line, ok := runtime.Caller(1)
if !ok {
return "unknown", 0
}
return filepath.Base(file), line
注意：file 是绝对路径，用 filepath.Base(file) 提取文件名；若需相对路径（如 internal/log/log.go），得手动裁剪 GOPATH 或 go mod 根目录，runtime.Caller 不提供该能力。
为什么有时 file 是空字符串或 line 是 0？
常见原因有三个：
- 编译时加了
-ldflags="-s -w"（剥离符号表），runtime.Caller失效，ok为false - 函数被编译器内联（尤其是小函数 +
-gcflags="-l"关闭内联可验证），导致栈帧丢失 - 在
init函数或包级变量初始化中调用，此时 goroutine 栈可能未完全建立
验证是否内联：运行 go build -gcflags="-m" your_file.go，看目标函数是否有 cannot inline 或 inlining candidate 提示。
性能开销有多大？值得在热路径用吗？
每次调用 runtime.Caller 需要遍历栈帧、解析 PC → 文件映射，实测单次耗时约 100–300ns（取决于栈深度和符号表大小）。在 QPS 过万的请求处理中频繁调用（比如每个 HTTP handler 都记日志位置），会明显拖慢吞吐量。
替代方案：
- 只在 debug / error 场景用（如
fmt.Errorf("xxx: %w", fmt.Errorf("at %s:%d", file, line))） - 预生成
func() (string, int)闭包，在初始化时捕获一次位置，避免运行时开销 - 用
debug.PrintStack()或runtime.Stack()替代，但它们更重，且不结构化
真正难的是平衡可读性与性能——位置信息对排错极有用，但不该成为默认开关。上线前建议压测对比开启/关闭时的 p99 延迟变化。
