热路径日志必须禁用标准log包，改用zap并关闭Lshortfile、避免反射格式化、前置等级判断、延迟计算字段、批量异步写入。核心是减少锁竞争、系统调用和CPU开销，而非简单换库。
热路径上直接调用 log.Printf 或 log.Println 必然引发 I/O 阻塞和锁竞争，这不是“可能慢”，而是确定会拖垮 QPS。必须绕过标准日志的同步写 + 反射格式化 + 调用栈检查三重开销。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
为什么热路径打日志等于自建性能瓶颈
Go 标准 log 包在每次调用时：
- 用 mutex.Lock() 串行化写入（哪怕你只写到 os.Stdout）
- 调用 runtime.Caller() 获取文件行号（若启用了 log.Lshortfile，压测中常占 CPU 5%~15%）
- 用反射解析 fmt.Sprintf 参数，再拼接字符串
- 每次都触发一次 write() 系统调用（哪怕缓冲区只有几个字节）
这些操作在 HTTP handler、循环体、定时 tick 中高频执行，goroutine 会卡在 syscall.Write 上，调度器无法腾挪，M 线程迅速耗尽。
用 zap.L().Info 替代 log.Printf，但必须配对禁用 Lshortfile
替换不是简单换包，关键在初始化时切断开销源头：
- 不要保留 log.Lshortfile 或 log.Llongfile —— 生产环境应设为 0
- zap 默认不带 caller，若真需定位，用 zap.AddCaller() 而非依赖 runtime.Caller()（它做了内联优化）
- 写日志时拆字段传参，别打包成 map 或结构体：zap.String("user_id", userID)，而非 zap.Any("data", map[string]string{"user_id": userID})
- 禁用采样器（zap.Sampling）除非你明确要降级；热路径更需要精准日志，而不是随机丢弃
日志等级判断前置，避免无效格式化
即使用了 zap，如果日志内容本身需要计算（比如拼接 JSON、调用 time.Now().String()），仍会在等级过滤前执行。正确做法是：
- 把条件判断提到最外层：if logger.Core().Enabled(zapcore.InfoLevel) { ... }
- 或更稳妥地用 logger.With(...).Check(zapcore.InfoLevel, nil) 手动触发检查
- 绝不写 logger.Info(fmt.Sprintf("uid=%s, ts=%s", u.ID, time.Now())) —— fmt.Sprintf 总是执行，哪怕日志被等级过滤掉
- 对高频但低价值日志（如每请求打一次 trace ID），改用 zap.Stringer("trace_id", zap.StringerFunc(func() string { return req.Header.Get("X-Request-ID") }))，延迟计算
异步写入不能靠 go log.Println() 这种伪异步
常见错误是给每条日志起一个 goroutine：go log.Printf(...)。这只会导致：
- goroutine 泛滥（QPS=1w 时瞬间起 1w 个）
- 底层仍共用带锁的 io.Writer，写入时照样阻塞
- 缓冲区未聚合，系统调用次数一点没减
真正可行的异步是：
- 用 zap.NewDevelopmentEncoderConfig() + zapcore.NewCore() 构建支持批量刷盘的 Core
- 或直接上 zap.WrapCore() 套一层 zapcore.Lock() + 自定义 buffer channel（但不如直接用 zap.NewProductionConfig().Build()）
- 若必须自研，channel 缓冲大小至少设为 1024，且后端 goroutine 必须做 buffer.Write() 批量落盘，而非逐条 WriteString
热路径日志真正的复杂点不在“怎么写”，而在“要不要写”——很多所谓“调试信息”其实可通过追踪 ID 关联链路追踪系统获取，硬塞进日志只会让缓冲区膨胀、GC 压力上升、磁盘写满。留一条干净的 zap.String("req_id", reqID) 就够了，其余交给 OpenTelemetry。
