go 标准库 log.fatal 会显示日志调用处（如自定义 fatal 函数内部）的行号，而非实际出错位置；通过 runtime.caller(1) 可获取上层调用者的文件与行号，结合自定义 logger 实现透明、精准的错误定位。
go 标准库 log.fatal 会显示日志调用处（如自定义 fatal 函数内部）的行号，而非实际出错位置；通过 runtime.caller(1) 可获取上层调用者的文件与行号，结合自定义 logger 实现透明、精准的错误定位。
在 Go 中，log.Fatal（及其变体 log.Print/log.Panic）默认记录的是日志语句所在位置的源码信息（即 mylog.Fatal(err) 所在行）。当你将其封装进 func fatal(err error) 后，行号就固定指向该函数内部，丢失了原始错误发生点（如 main 中 os.Open 调用行），极大削弱调试效率。
解决的关键在于：绕过默认的 log.Lshortfile 行号捕获机制，手动注入真实调用位置。Go 的 runtime.Caller(n) 正是为此而生——它返回第 n 层调用栈的文件名、行号、函数名等信息。其中 Caller(0) 是当前函数，Caller(1) 即其直接调用者（也就是你期望的 fatal(err) 被调用的位置）。
以下是推荐的实现方式：
package main
import (
"log"
"os"
"runtime"
)
var mylog = log.New(os.Stderr, "app: ", log.LstdFlags)
// fatal 在 err 非 nil 时终止程序，并精确打印调用方（而非本函数）的文件与行号
func fatal(err error) {
if err != nil {
// 获取调用 fatal 的那一行信息（Caller(1)）
_, file, line, ok := runtime.Caller(1)
if !ok {
file = "unknown"
line = 0
}
// 构造带自定义位置前缀的日志消息
msg := append([]interface{}{file + ":" + fmt.Sprint(line) + ":"}, err)
mylog.Fatal(msg...)
}
}
// 注意：需显式导入 fmt（因示例中使用了 fmt.Sprint）
import "fmt"
func main() {
_, err := os.Open("some-crazy-non-existent-file")
fatal(err) // ← 此处的文件名与行号将被准确记录
}⚠️ 注意事项：
- runtime.Caller 开销极小，但非零；在性能极端敏感场景应权衡；
- log.Lshortfile 必须禁用（即不传入 log.Lshortfile 标志），否则 mylog 会自行追加另一份行号，造成冗余或冲突；
- 若需兼容 log.Printf 风格的格式化（如 fatal(fmt.Errorf("failed: %w", err))），可进一步封装为 fatalf(format string, args ...interface{})，并在其中调用 runtime.Caller(1) + fmt.Sprintf；
- 此方案完全透明：调用方无需修改任何代码，仅替换 mylog.Fatal(err) 为 fatal(err) 即可获得精准溯源能力。
总结：Go 虽无宏系统，但 runtime.Caller 提供了运行时元编程能力，使封装型错误处理函数既能保持简洁性，又不牺牲调试关键信息——这是构建健壮、可维护 CLI 工具和后台服务的重要实践。
