go 标准库的 log.logger 默认会记录日志调用点的文件与行号，但直接封装其方法（如 printf）会导致行号指向封装函数内部。本文介绍通过调用 output() 方法并指定 calldepth=2，精准还原原始调用位置的可靠方案。
go 标准库的 log.logger 默认会记录日志调用点的文件与行号，但直接封装其方法（如 printf）会导致行号指向封装函数内部。本文介绍通过调用 output() 方法并指定 calldepth=2，精准还原原始调用位置的可靠方案。
在 Go 中使用 log.Lshortfile（或 log.Llongfile）标志时，log.Logger 会自动在每条日志前添加调用位置信息，例如 main.go:23:。这一行为依赖于运行时调用栈分析——Logger 内部通过 runtime.Caller() 获取调用者帧，并默认跳过 2 层：第 0 层是 runtime.Caller 自身，第 1 层是 Logger 的公开方法（如 Printf），因此第 2 层才是用户实际调用日志的地方。
然而，当你编写类似以下的封装函数时：
func info(pattern string, args ...interface{}) {
myLogger.Printf(pattern+"\n", args...) // ❌ 行号指向此行（即 info 函数内部）
}Printf 方法内部已将 calldepth 固定为 2，导致 runtime.Caller(2) 返回的是 info 函数体内的位置，而非调用 info() 的那一行——这显然违背了调试与可观测性的初衷。
✅ 正确解法是绕过 Printf 等高层方法，直接调用 Logger.Output(calldepth, message)，并显式设置 calldepth = 2：
var myLogger = log.New(os.Stdout, "[my] ", log.Lshortfile)
func info(pattern string, args ...interface{}) {
msg := fmt.Sprintf(pattern, args...)
myLogger.Output(2, msg) // ✅ 跳过 info() 和 Output() 两层，定位到调用 info() 的行
}? 为什么是
calldepth = 2？
myLogger.Output(2, ...)中的2表示从Output调用点向上数 2 帧：
- 帧 0：
runtime.Caller(2)所在位置（Output内部）- 帧 1：
info()函数中的myLogger.Output(...)调用- 帧 2：用户代码中调用
info(...)的那行 ← 我们想要的位置
完整可运行示例：
package main
import (
"fmt"
"log"
"os"
)
var myLogger = log.New(os.Stdout, "[my] ", log.Lshortfile)
func info(pattern string, args ...interface{}) {
msg := fmt.Sprintf(pattern, args...)
myLogger.Output(2, msg)
}
func main() {
log.SetFlags(log.Lshortfile)
log.Println("direct log") // 输出: main.go:16: direct log
info("wrapped log") // 输出: [my]main.go:17: wrapped log
}输出结果：
main.go:16: direct log [my]main.go:17: wrapped log
? 注意事项：
- 不需要手动拼接
\n：log.Logger在Output()中会自动补行尾换行符（若消息末尾无\n）； -
Output()第二个参数是纯字符串，因此需预先用fmt.Sprintf格式化； - 若封装多个级别（如
info→debug→log），需相应增加calldepth（例如三层嵌套则设为3），但建议保持封装扁平； - 此方案完全兼容
log.Ldate、log.Ltime、log.Lmicroseconds等所有标志，无需额外处理时间戳逻辑。
总结：避免封装 Printf/Println 等方法，改用 Logger.Output(2, formattedString) 是保留真实调用行号最简洁、最健壮的方式——它不依赖反射或 hack，而是顺应 Go 日志设计的原生机制。
