Go服务日志标准化关键在于结构、字段、上下文和输出管道的一致性，必须使用结构化日志（如zap）、统一字段命名（如trace_id、user_id）、禁止字符串拼接、敏感信息过滤、HTTP请求日志外层统一采集、分级采样，并确保trace_id全链路透传。
Go 服务的日志标准化不是靠加个 logrus 或 zap 就算完成，关键在结构、字段、上下文和输出管道的一致性。没规范的结构化日志，查问题时等于在文本里盲搜。
日志必须用结构化格式，禁止拼接字符串
拼接日志（如 fmt.Sprintf("user %s login failed at %v", uid, time.Now())）无法被日志平台提取字段，也难做聚合分析。所有日志输出必须走结构化写入器。
- 推荐使用
zap.Logger（性能高、无反射、支持字段复用），避免logrus默认的 JSON encoder（有锁、字段拷贝开销大） - 每条日志至少包含：
level、ts（ISO8601 时间）、caller（文件:行号）、msg、trace_id（若已接入链路追踪） - 业务字段必须显式传入，不拼进
msg：用logger.Info("user login start", zap.String("user_id", uid), zap.String("ip", ip))，而非logger.Info("user login start user_id="+uid)
定义统一日志字段名与语义，避免各团队自定义
字段命名不统一会导致 ELK/Kibana 查询困难。例如有人用 user_id，有人用 uid，有人用 userId，搜索时得写三遍。
- 强制约定核心字段名（小写+下划线）：
trace_id、span_id、service_name、host、pid、req_id（单次 HTTP 请求 ID）、user_id、status_code、http_method、http_path - 错误日志必须带
err字段（类型为error），由 zap 自动展开堆栈；不要只打err.Error() - 禁止在日志中写敏感字段（如
password、id_card、token），需在中间件或日志封装层过滤
HTTP 请求日志必须独立采集且带完整上下文
只靠业务代码打日志，会漏掉 4xx/5xx、超时、panic 等场景。必须在最外层（如 Gin 的 middleware 或 net/http HandlerFunc）统一拦截。
立即学习“go语言免费学习笔记（深入）”；
- 记录时机：响应写出后（
rw.WriteHeader()后），确保能拿到真实status_code和body_size - 必采字段：
req_id（从 header 提取或生成）、http_method、http_path、status_code、duration_ms、client_ip、user_agent（可选）、referer（可选） - 避免记录请求体（
body）和响应体（body），除非调试需要且已脱敏；生产环境禁用
日志级别与采样策略要按环境分级控制
开发环境全量 DEBUG 没问题，但线上全开 Debug 会吃光磁盘和 IO，还可能暴露内部逻辑。
- 默认线上只输出
Info及以上；Debug日志必须用logger.Debug("xxx", zap.Bool("enabled", debugEnabled))包一层开关 - 高频日志（如每秒上千次的计数器、心跳）必须采样：用
zap.AtomicLevel动态调低级别，或用zapsampling库做概率采样（如 0.1%） - panic / fatal 日志必须同步写入本地文件 + 推送到远端（如 Loki），防止进程崩溃导致日志丢失
func NewLogger(service string) *zap.Logger {
cfg := zap.NewProductionConfig()
cfg.Level = zap.NewAtomicLevelAt(zap.InfoLevel)
cfg.OutputPaths = []string{"stdout"}
cfg.ErrorOutputPaths = []string{"stderr"}
cfg.EncoderConfig.TimeKey = "ts"
cfg.EncoderConfig.EncodeTime = zapcore.ISO8601TimeEncoder
cfg.EncoderConfig.CallerKey = "caller"
cfg.EncoderConfig.EncodeCaller = zapcore.ShortCallerEncoder
cfg.InitialFields = map[string]interface{}{"service": service}
logger, _ := cfg.Build()
return logger
}
真正难的不是写日志，是让所有人——包括新来的同事、第三方 SDK、定时任务、gRPC 服务——都遵守同一套字段语义和注入方式。最容易被忽略的是 trace_id 的透传一致性：HTTP header、context、日志字段、DB 注释，四个地方必须对齐，否则一查就断。
