Go 标准日志的 log.Fatal 在封装成工具函数后会丢失真实错误发生位置的行号；通过 runtime.Caller(1) 可获取上层调用者（如 main）的文件与行号，并结合自定义 log.Logger 实现透明、精准的错误定位。
go 标准日志的 `log.fatal` 在封装成工具函数后会丢失真实错误发生位置的行号；通过 `runtime.caller(1)` 可获取上层调用者（如 `main`）的文件与行号，并结合自定义 `log.logger` 实现透明、精准的错误定位。
在 Go 开发中，为避免重复编写 if err != nil { log.Fatal(err) } 这类样板代码，开发者常将错误检查逻辑抽象为辅助函数（如 fatal(err)）。但直接封装会导致日志输出的 Lshortfile 行号指向该辅助函数内部（如 utils.go:15），而非实际出错的业务代码行（如 main.go:22），极大降低调试效率。
根本原因在于：log.Logger 的 Lshortfile 标志依赖运行时栈帧自动推导调用位置，而封装函数新增了一层调用栈，log.Fatal 默认抓取的是当前函数（即 fatal）的位置。
✅ 正确解法是手动捕获上一级调用信息，并构造带准确路径/行号的前缀，再交由 log.Logger 输出：
package main
import (
"log"
"os"
"runtime"
"strings"
)
var mylog = log.New(os.Stderr, "app: ", log.LstdFlags|log.Lshortfile)
// fatal 检查错误，若非 nil 则以调用者（而非本函数）的文件和行号记录 fatal 日志
func fatal(err error) {
if err == nil {
return
}
// Caller(1) 获取调用 fatal 的那一行信息（即 main.go 中 fatal(err) 所在行）
_, file, line, ok := runtime.Caller(1)
if !ok {
file = "unknown"
line = 0
}
// 提取短文件名（去掉 GOPATH/GOROOT 前缀），与 log.Lshortfile 行为一致
shortFile := file
if lastSlash := strings.LastIndex(file, "/"); lastSlash >= 0 {
shortFile = file[lastSlash+1:]
}
// 构造符合 log 格式的前缀："file:line: "
prefix := shortFile + ":" + string(rune(line+'0')) + ": "
// 临时修改 logger 前缀，输出后恢复（注意：log 不支持 per-call 前缀，故需重建 logger）
// 更推荐方式：禁用 Lshortfile，手动注入位置信息
mylog.SetPrefix("app: " + prefix)
mylog.Fatal(err)
// 恢复原始前缀（可选，若全局唯一 logger 且多 goroutine 使用需加锁）
mylog.SetPrefix("app: ")
}
func main() {
_, err := os.Open("some-crazy-non-existent-file")
fatal(err) // ← 此处的行号将正确显示在日志中
}
⚠️ 注意事项：
- runtime.Caller(1) 是关键：0 表示当前函数，1 表示其直接调用者；
- log.Lshortfile 与手动拼接的 file:line 本质相同，但封装后无法直接复用该标志，因此建议禁用 log.Lshortfile，完全由 Caller 控制位置信息；
- 若需线程安全，mylog.SetPrefix 需配合 sync.Mutex，或更优方案是使用 log.New 为每次 fatal 创建临时 logger；
- 生产环境推荐使用结构化日志库（如 zap 或 zerolog），它们原生支持 caller skip 功能（如 WithCallerSkip(1)）。
总结：Go 虽无宏，但 runtime.Caller 提供了足够底层的能力实现“行号透明”的错误封装。合理利用栈帧信息，即可在保持代码简洁的同时，不牺牲可观测性与调试体验。
