Go标准库log包不行，因其输出纯文本、无日志级别、不支持结构化字段、无法注入上下文（如trace_id）、不能对接ELK/Loki，且同步写stderr无缓冲，高并发下成性能瓶颈。
为什么直接用 log 包不行？
企业级日志分析需要结构化、可过滤、带上下文、能对接 ELK 或 Loki，而 Go 标准库 log 包输出纯文本、无字段、不支持 level 动态控制、无法打点埋点。一旦日志量上万行/秒，log.Printf 会成为性能瓶颈——它默认用 os.Stderr 同步写，没缓冲、没异步队列、没采样机制。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 立刻停用
log.Println做业务日志，仅保留用于启动/崩溃等极简诊断 - 选一个支持 zapcore 的日志库（如
uber/zap），它底层用ring buffer+atomic操作，吞吐比log高 5–10 倍 - 避免在日志中拼接字符串：
logger.Info("user " + u.Name + " login")→ 改用结构化字段：logger.Info("user login", "user_id", u.ID, "ip", r.RemoteAddr)
zap.Logger 怎么配才不丢日志？
常见错误是用 zap.NewDevelopment() 上生产——它默认把日志打到 os.Stdout，进程重启或 stdout 被重定向时日志就丢了；更糟的是，它不启用 Syncer 缓冲，高并发下容易 panic。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 生产环境必须用
zap.NewProduction()，它自动启用WriteSyncer+lumberjack.Logger轮转 - 自己封装
zap.Config时，务必设置EncoderConfig.EncodeLevel = zapcore.CapitalLevelEncoder，否则 ES/Kibana 识别不了 level 字段 - 如果对接 Loki，需用
zapcore.NewConsoleEncoder并开启EncodeTime和EncodeCaller，Loki 的labels依赖这些字段提取
如何让日志自带 traceID 和 requestID？
没有上下文 ID 的日志等于废日志。Gin/echo 等框架的中间件只负责注入，但 zap 默认不感知 HTTP context，你得手动把值从 context.Context 提出来塞进 logger。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在 middleware 中生成
trace_id（用google.uuid.New().String()），存入ctx：ctx = context.WithValue(r.Context(), "trace_id", tid) - 不要用
logger.With(...)在每个 handler 里重复加字段，而是封装一个WithContext(ctx)方法，内部调用ctx.Value("trace_id")提取并返回新 logger - 注意：Go 1.21+ 的
context.WithValue是 unsafe 的，若用go vet检查出context value type is not comparable，就把trace_id定义为type TraceID string，而非string
日志写文件还是发 Kafka？
写本地文件看似简单，但磁盘 IO 不可控，节点宕机就丢数据；直发 Kafka 看似可靠，但 zap 没内置 Kafka hook，硬接会拖慢主流程。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 优先走
file + filebeat：用lumberjack控制单文件大小和保留天数，再由 filebeat 投递到 Kafka/ES，解耦写入与投递 - 如果必须直发 Kafka，别用
sarama.AsyncProducer—— 它的Errors()channel 容量有限，满后会 panic；改用sarama.SyncProducer+time.AfterFunc做超时兜底 - 所有外发通道都得加 fallback：Kafka 不可用时自动切回本地文件，靠
atomic.Bool控制开关，避免雪崩
真正难的不是怎么记日志，是怎么让每条日志在 3 秒内被查到、能按 service_name + status_code + duration_ms 组合过滤、且不因某条日志格式错导致整条 pipeline 卡住——这些得靠 schema validation 和采样策略卡死在接入层。
