本文介绍如何在 Go log 包中为每条日志动态添加运行时信息（如调用函数名、请求 ID 等），而非仅依赖固定前缀；涵盖手动注入、SetPrefix 动态设置、性能权衡及现代替代方案。
本文介绍如何在 go `log` 包中为每条日志动态添加运行时信息（如调用函数名、请求 id 等），而非仅依赖固定前缀；涵盖手动注入、`setprefix` 动态设置、性能权衡及现代替代方案。
Go 标准库的 log 包轻量简洁，但其 *log.Logger 的前缀（prefix）是全局且静态设定的——通过 log.New() 初始化后，SetPrefix() 可修改，但无法自动感知调用上下文。若需在每条日志中注入动态信息（例如当前函数名、goroutine ID 或 trace ID），需主动介入日志生成流程。
✅ 方案一：手动拼接（最轻量、推荐用于简单场景）
最直接的方式是在调用 Info.Printf() 等方法时显式传入动态内容：
func processUser(id int) {
fn := getFuncName() // 替换为你封装的 _enter() 返回函数名
Info.Printf("[%s] processing user id=%d", fn, id)
}
// 输出示例：INFO: 2024/05/20 14:22:33 main.go:42: [processUser] processing user id=123优点：零额外开销、完全可控、无需修改 logger 实例；缺点：需人工编写，易遗漏。
? getFuncName() 可优化为安全、无 panic 的版本：
func getFuncName() string { if pc, _, _, ok := runtime.Caller(1); ok { if f := runtime.FuncForPC(pc); f != nil { name := f.Name() if i := strings.LastIndex(name, "."); i >= 0 { return name[i+1:] } return name } } return "unknown" }
✅ 方案二：按需调用 SetPrefix()（适合短生命周期上下文）
利用 logger.SetPrefix() 在日志前动态插入上下文，适用于单次或小范围日志输出：
func handleRequest(w http.ResponseWriter, r *http.Request) {
prefix := fmt.Sprintf("INFO: [%s] %s: ", getFuncName(), r.URL.Path)
Info.SetPrefix(prefix) // 临时覆盖前缀
defer Info.SetPrefix("INFO: ") // 恢复默认（注意：非 goroutine 安全！）
Info.Println("request started")
// ... business logic ...
Info.Println("request completed")
}⚠️ 重要限制：SetPrefix 是全局修改，在并发场景下（如 HTTP handler）极易引发竞态——多个 goroutine 同时调用 SetPrefix 会相互覆盖。因此该方案仅适用于单 goroutine 场景或严格串行日志链路。
✅ 方案三：封装结构体 + 方法代理（平衡灵活性与安全性）
为规避竞态并提升可维护性，可将 logger 封装为带上下文能力的结构体：
type ContextLogger struct {
logger *log.Logger
prefix string
}
func (l *ContextLogger) WithPrefix(p string) *ContextLogger {
return &ContextLogger{
logger: l.logger,
prefix: fmt.Sprintf("%s%s", l.prefix, p),
}
}
func (l *ContextLogger) Printf(format string, v ...interface{}) {
msg := fmt.Sprintf(format, v...)
l.logger.Printf("%s%s", l.prefix, msg)
}
// 使用示例
func handler(w http.ResponseWriter, r *http.Request) {
ctxLog := &ContextLogger{logger: Info, prefix: fmt.Sprintf("[%s]%s: ", getFuncName(), r.URL.Path)}
ctxLog.Printf("received request from %s", r.RemoteAddr)
}此方式避免了全局状态污染，支持链式构建上下文（如 .WithPrefix("trace-id:abc123").WithPrefix("user:alice")），是标准库场景下的最佳实践演进方向。
⚠️ 注意事项与性能提醒
- runtime.Caller(n) 和 runtime.FuncForPC() 存在可观测开销（微秒级），高频日志中应谨慎使用；生产环境建议结合采样（如仅 error 日志注入函数名）。
- 标准 log 包不支持字段化（structured logging），无法原生输出 JSON 或键值对。若需 {"func":"handler","status":"ok","latency_ms":12.3} 这类日志，请果断升级。
- log.Lshortfile 已包含文件名与行号，函数名属于冗余信息，需评估真实可观测价值。
? 推荐升级：采用结构化日志库（如 logrus / zap）
对于中大型项目，强烈建议迁移到专业日志库：
import log "github.com/sirupsen/logrus"
func init() {
log.SetFormatter(&log.TextFormatter{FullTimestamp: true})
log.SetLevel(log.InfoLevel)
}
func handler(w http.ResponseWriter, r *http.Request) {
log.WithFields(log.Fields{
"func": "handler",
"path": r.URL.Path,
"method": r.Method,
"ip": getClientIP(r),
}).Info("HTTP request received")
}
// 输出：INFO[2024-05-20 14:22:33] HTTP request received func=handler path=/users method=GET ip=192.168.1.100logrus、zap、zerolog 等均支持字段注入、Hook 扩展、JSON 输出与上下文传播，且 API 更符合现代 Go 工程实践——它们不是“更复杂”，而是把本该由开发者手动完成的上下文管理，交由成熟抽象统一处理。
总之：标准库够用，但动态日志需主动设计；简单脚本用拼接，关键服务请拥抱结构化日志。
