直接用 Go 原生 log 包写文件会拖垮微服务，因其默认同步写磁盘、无缓冲无异步无批处理，高并发下 I/O 成为瓶颈；应改用 lumberjack + zap 组合实现高性能结构化日志输出与轮转。
为什么直接用 log 包写文件会拖垮微服务
Go 原生 log 包默认是同步写磁盘的，每条日志都触发一次 write() 系统调用，在高并发场景下（比如每秒上千请求），I/O 成为瓶颈，CPU 空转、延迟飙升，甚至触发容器 OOM。这不是日志量大才出问题，而是写法本身没缓冲、没异步、没批处理。
- 避免直接调用
log.SetOutput(os.File)—— 这等于把所有日志直塞磁盘 - 别用
log.Printf打调试级日志到文件 —— 微服务里DEBUG日志应走内存队列或丢弃，而非落盘 - 注意
log.Logger实例不是线程安全的？错，它是线程安全的，但性能不等于安全 —— 并发写同一文件句柄仍会串行阻塞
用 lumberjack + zap 组合做日志轮转和高性能输出
lumberjack 是轻量级日志切割库，只负责按大小/时间切文件；zap 是 Uber 开源的结构化日志库，核心优势是零分配（zero-allocation）和异步写入能力。两者组合能兼顾可维护性与吞吐量。
-
lumberjack.Logger必须显式设置MaxSize（单位 MB）、MaxBackups和Compress: true，否则旧日志不清理、不压缩，磁盘迟早爆 -
zap.NewProduction()默认用consoleEncoder，要输出到文件必须用zapcore.AddSync()包裹lumberjack.Logger - 示例关键片段：
core := zapcore.NewCore(encoder, zapcore.AddSync(&lumberjack.Logger{Filename: "/var/log/myapp.log", MaxSize: 100, MaxBackups: 5, Compress: true}), zapcore.InfoLevel)<br>logger := zap.New(core)
采集端不该自己实现 HTTP 上报，优先复用 filebeat 或 fluent-bit
在容器环境里，让业务进程自己 HTTP POST 日志到 Loki/Elasticsearch，既增加服务复杂度，又引入重试、背压、连接池等额外问题。日志采集应解耦 —— 应用只负责写本地文件，由专用 agent 负责读取、过滤、转发。
- Pod 中 sidecar 启动
fluent-bit，配置tail输入插件监听/var/log/myapp.log，用regex提取level、ts、trace_id字段 - Go 服务里日志格式必须结构化：用
zap.String("trace_id", traceID)而非拼接字符串，否则 fluent-bit 解析失败 - 禁止在 Go 代码里调用
http.Post发日志 —— 一旦目标不可达，日志协程堆积，内存泄漏风险极高
本地调试时用 development encoder，上线必须切回 production
zap 的 development encoder 会美化输出、加颜色、打印调用栈文件行号，对调试友好，但序列化开销大、JSON 不紧凑；production encoder 去掉所有装饰，字段名缩写（如 lvl 替代 level），适合日志系统解析。
立即学习“go语言免费学习笔记（深入）”；
- 本地
go run main.go可用zap.NewDevelopment()，但 CI 构建镜像时必须通过构建 tag 或环境变量强制启用zap.NewProduction() - 别依赖
os.Getenv("ENV") == "prod"切换 —— 容器里环境变量易被覆盖，推荐编译期注入：go build -ldflags="-X main.env=prod" - 字段名缩写不可自定义 ——
productionencoder 内置固定映射，改了就和 fluent-bit 的 parser 对不上
真正难的不是选库，而是让日志路径、权限、rotate 策略、agent 配置、结构字段这五者始终对齐 —— 少一个，查问题时就少一条线索。
