标准 log 包不适合 Web 服务日志，因其不支持结构化、多级别动态切换、按时间轮转、并发写入隔离、JSON 输出、模块化输出及上下文透传。
为什么标准 log 包不适合 Web 服务日志
Go 标准库的 log 包默认输出到 stderr，不支持结构化、多级别动态切换、按时间轮转或并发写入隔离——这些在 Web 服务中全是刚需。比如 HTTP 请求日志需要同时记录路径、状态码、耗时、IP，而 log.Printf 只能拼字符串，查问题时得靠正则硬扒。
更实际的问题是：多个 goroutine 并发写同一个 *log.Logger 实例时，日志行会错乱（如两行日志内容混在一起），因为标准包没内置锁或缓冲队列。
- 不支持 JSON 输出，无法直接对接 ELK 或 Loki
- 无法为不同模块设置独立输出目标（如 auth 日志单独写文件）
- 没有上下文透传能力，一次请求分散在多个函数里，日志串不起来
用 zap 实现高性能结构化日志
zap 是目前 Go 生态最主流的结构化日志库，性能比 logrus 高 4–10 倍，核心优势是零内存分配（logger.Info 调用不触发 GC）和可组合编码器（JSON / console）。
生产环境推荐使用 zap.NewProduction()，它自动启用 JSON 编码、时间纳秒级精度、调用栈采样、错误字段增强；开发阶段可用 zap.NewDevelopment() 输出带颜色的易读格式。
立即学习“go语言免费学习笔记（深入）”；
- 初始化后务必调用
logger.Sync()关闭前，否则最后一段日志可能丢失 - 避免高频打点用
logger.Info，改用logger.Debug并通过zap.IncreaseLevel(zap.DebugLevel)动态开启 - 记录 HTTP 请求建议封装中间件，把
http.ResponseWriter包装成带状态码捕获的 wrapper，再用logger.With(zap.String("path", r.URL.Path), zap.Int("status", statusCode))打点
按请求上下文串联日志：用 context.Context + zap 的 With
Web 服务中一次请求常横跨多个 handler、service、dao 层，靠时间戳对齐日志极不可靠。正确做法是把 zap.Logger 注入 context.Context，每层都用 logger.With(zap.String("request_id", reqID)) 衍生新 logger。
生成唯一 request_id 推荐用 uuid.NewString()（Go 1.20+），不要用时间戳或自增 ID —— 后者在高并发下不唯一且无序。
- 中间件中应从
ctx取 logger：logger := ctx.Value("logger").(*zap.Logger)，或更安全地用ctx.Value(loggerKey)（定义私有类型作 key） - 不要在每个函数里重复
logger.With(...)，而是用logger.WithOptions(zap.AddCaller())开启调用位置，减少手动传参 - 敏感字段如
Authorization头、用户密码，必须显式过滤，zap.String("auth", "[redacted]")比依赖日志脱敏规则更可靠
日志落盘与轮转：别自己实现，用 lumberjack 配合 zap
zap 本身不处理文件切割，需搭配 lumberjack（官方推荐的轮转 writer）。它支持按大小、时间、保留天数三重策略，且写入原子安全——不会因切文件导致日志丢失或损坏。
关键配置项：MaxSize（单位 MB，建议 100–500）、MaxBackups（保留旧文件数，建议 7）、MaxAge（过期天数，建议 30）。注意 LocalTime: true 必须设为 true，否则轮转基于 UTC 时间，和本地运维习惯不符。
- Windows 下路径分隔符要用
filepath.Join，避免硬写"logs/app.log"导致路径错误 - 日志目录需提前创建并检查权限，
os.MkdirAll+os.Chmod不足以保证可写，上线前务必用os.OpenFile测试写入 - 如果用 systemd 管理进程，禁用
StandardOutput=journal，否则zap写文件的同时日志又进 journal，造成重复
