本文介绍如何利用 go 的 `runtime.caller` 在日志中自动注入调用点的文件名、函数名和行号，避免手动拼接冗余字符串，并提供可复用的封装方案与注意事项。
在 Go 日志调试中，手动写入如 "main.go:myFunction(): There was an error:" 这类硬编码位置信息不仅易出错、难维护，还会在代码重构（如重命名函数或移动文件）后失效。理想方式是在运行时动态获取调用栈信息，精准定位日志源头。
Go 标准库的 runtime 包提供了 runtime.Caller(depth int) 函数，它能返回调用栈中指定深度的程序计数器（PC）、源文件路径、行号及是否有效标志。配合 runtime.FuncForPC(pc)，还可解析出对应的函数全名（含包名）。
以下是一个简洁、可直接复用的辅助函数：
import (
"fmt"
"runtime"
)
// Trace 返回当前调用点的文件路径、函数名、行号和有效性标志
func Trace() (file string, funcName string, line int, ok bool) {
pc, file, line, ok := runtime.Caller(1) // depth=1 表示上一层调用者
if !ok {
return "", "", 0, false
}
f := runtime.FuncForPC(pc)
if f == nil {
return file, "", line, true
}
return file, f.Name(), line, true
}使用示例：
func myFunc() {
file, fn, line, ok := Trace()
if ok {
fmt.Printf("%s:%s:%d: There was an error\n", file, fn, line)
// 输出类似：/path/to/main.go:main.myFunc:15: There was an error
}
}
func main() {
myFunc()
}⚠️ 注意事项：
- runtime.Caller(1) 中的 1 表示跳过 Trace() 自身，获取其调用者的上下文；若在封装的日志函数中使用，需根据实际调用链调整 depth（例如再包一层则用 Caller(2)）；
- FuncForPC 可能返回 nil（如内联函数、编译优化关闭符号表等），建议做空值判断；
- 生产环境高频日志中频繁调用 runtime.Caller 有一定性能开销（涉及栈遍历与字符串解析），如需极致性能，建议结合 build tags 在 debug 模式下启用，发布版降级为无位置信息日志；
- go generate 并非本方案必需——它适用于编译前静态代码生成（如从模板生成桩代码），而位置信息天然具有运行时动态性，因此 runtime.Caller 是更自然、更可靠的选择；强行用 go generate 替换 %fn% 等占位符反而会丢失真实调用位置（因生成后代码固定，无法反映实际执行路径）。
综上，应优先使用 runtime.Caller 实现运行时位置注入，而非试图用 go generate 做静态替换。它轻量、准确、无需额外构建步骤，是 Go 生态中记录诊断信息的标准实践。
