Go 标准库 log.Logger 默认记录的是封装函数内部的文件行号；通过调用 Logger.Output() 并指定 callDepth = 2（或更高）可跳过包装层，精准定位到业务代码的调用位置。
go 标准库 `log.logger` 默认记录的是封装函数内部的文件行号；通过调用 `logger.output()` 并指定 `calldepth = 2`（或更高）可跳过包装层，精准定位到业务代码的调用位置。
在 Go 中封装全局日志器（如提供 Debug()、Info() 等便捷方法）时，一个常见痛点是：日志输出的文件路径和行号总是指向日志封装函数自身（如 logging.go:16），而非真正调用日志的业务代码（如 main.go:6）。这是因为 log.Logger.Printf() 内部固定使用 Output(2, ...) —— 数字 2 表示向上追溯 2 层调用栈：第 0 层是 Output 自身，第 1 层是 Printf，第 2 层才是调用 Printf 的位置。而当你在 Debug() 函数中调用 Logger.Printf()，调用栈就变成了：
main.main() ← 期望显示的位置（第 0 层）
└── logging.Debug() ← 封装函数（第 1 层）
└── Logger.Printf() → 内部调用 Logger.Output(2, ...)
→ 实际查到的是 Debug 函数内部（即第 2 层 = logging.go:16）因此，解决方案是绕过 Printf，直接调用底层 Logger.Output()，并显式设置 callDepth = 2 —— 这里的 2 指从 Output 调用点起，向上跳过 当前函数（Debug）和 Output 自身，最终定位到 main.main()：
// src/logging/logging.go
package logging
import (
"fmt"
"log"
"os"
)
var Logger *log.Logger
func init() {
Logger = log.New(os.Stdout, "[Debug]", log.Llongfile|log.LstdFlags)
}
func Debug(format string, v ...interface{}) {
// 关键：不用 Printf，改用 Output，并设 callDepth = 2
// 2 表示：跳过 Output 和 Debug 两层，定位到调用 Debug 的地方
msg := fmt.Sprintf(format, v...)
Logger.Output(2, msg) // ✅ 正确显示 main.go:6
}? callDepth 的计算逻辑（以 Debug("...") 调用为例）：
- Logger.Output(2, ...) 执行时，运行时从该行开始向上遍历调用栈；
- depth=0 → Output 函数内部；
- depth=1 → Debug 函数内部（即 Logger.Output(...) 这一行）；
- depth=2 → main.main() 中调用 logging.Debug(...) 的那一行 —— 这正是我们想要的。
注意事项：
- 若封装层级更深（例如 Debug → logHelper → Logger.Output），需相应增大 callDepth（如 3）；建议统一抽象为常量或通过 runtime.Caller 动态计算，但对简单封装，2 是标准值；
- 不要误用 log.Lshortfile 或 log.Llongfile 的开关控制——它们只影响格式，不解决调用栈深度问题；
- 使用 Output 替代 Printf 意味着你需要手动格式化字符串（如用 fmt.Sprintf），但换来的是精确的源码定位，对调试和可观测性至关重要。
综上，只需将封装函数中的 Logger.Printf(...) 替换为 Logger.Output(2, fmt.Sprintf(...))，即可让日志始终指向真实业务调用点，大幅提升日志排查效率。
