go 标准库 log.fatal 在封装成工具函数后会丢失原始错误发生位置的行号；本文介绍通过 runtime.caller(1) 获取上层调用栈信息，动态重写日志前缀，使自定义 fatal 函数完全透明、精准定位错误源头。
go 标准库 log.fatal 在封装成工具函数后会丢失原始错误发生位置的行号；本文介绍通过 runtime.caller(1) 获取上层调用栈信息，动态重写日志前缀，使自定义 fatal 函数完全透明、精准定位错误源头。
在 Go 开发中，为避免重复的 if err != nil { log.Fatal(err) } 模式，我们常将错误处理逻辑抽象为辅助函数（如 fatal(err)）。但直接封装会导致 log.Fatal 输出的文件名与行号指向该辅助函数内部（如 fatal.go:12），而非实际出错的调用处（如 main.go:22），极大削弱调试效率。
根本原因在于：log.Logger 默认通过 runtime.Caller(0) 获取当前执行位置来生成 Lshortfile 信息，而封装函数自身就是第 0 层调用。解决思路是——绕过默认行为，在进入 log.Fatal 前手动获取真实调用位置，并临时替换 logger 的 prefix 或使用自定义输出。
最简洁可靠的方案是：利用 runtime.Caller(1) 获取调用 fatal 函数的源码位置（即 main.go:22），构造带正确路径信息的错误消息，再交由 logger 输出：
package main
import (
"log"
"os"
"runtime"
"strings"
)
var mylog = log.New(os.Stderr, "app: ", log.LstdFlags)
// fatal 会在 err 非 nil 时终止程序，并精确报告调用处的文件与行号
func fatal(err error) {
if err == nil {
return
}
// 获取调用 fatal 的上层函数位置（Caller(1)）
_, file, line, ok := runtime.Caller(1)
if !ok {
file = "unknown"
line = 0
}
// 提取文件名（去除完整路径，保留 base name）
shortFile := file
if i := strings.LastIndex(file, "/"); i != -1 {
shortFile = file[i+1:]
}
// 构造含真实位置的错误消息
msg := strings.TrimSpace(err.Error())
fullMsg := shortFile + ":" + string(rune(line)) + ": " + msg
// 使用无 Lshortfile 标志的 logger，避免重复添加行号
mylog.SetFlags(log.LstdFlags) // 确保仅含时间戳和自定义前缀
mylog.Fatal(fullMsg)
}
func main() {
_, err := os.Open("some-crazy-non-existent-file")
fatal(err) // 输出示例：app: 2024/05/20 14:32:11 main.go:22: open some-crazy-non-existent-file: no such file or directory
}
⚠️ 注意事项：
- runtime.Caller(n) 开销极小，但在高频路径中仍需权衡；本场景属错误退出，无需顾虑性能。
- log.Lshortfile 必须禁用（即不传入该 flag），否则会与手动拼接的 file:line 冲突或重复。
- 若需兼容 log.Llongfile 或其他 flag，可改用 log.Output() 直接写入，完全控制输出格式。
- 此方案不依赖第三方库，纯标准库实现，适用于所有 Go 版本（≥1.0）。
总结：Go 虽无宏系统，但 runtime.Caller 提供了运行时反射能力，足以支撑“行号透明”的封装需求。将错误处理函数设计为栈帧感知型，即可兼顾代码复用性与调试友好性——这是构建健壮 CLI 工具和服务器应用的关键实践之一。
