应使用结构化JSON日志中间件，通过包装responseWriter获取状态码，异步批量写入并脱敏敏感字段，配合lumberjack实现文件轮转。
用 net/http 中间件记录结构化访问日志
Go 标准库没有内置访问日志中间件，必须自己封装。关键不是“打日志”，而是避免阻塞请求、不丢失字段、不拖慢响应。
常见错误是直接在 HandlerFunc 里调用 log.Printf，这会导致日志写入磁盘时阻塞 goroutine；更糟的是，如果用 time.Now() 记录开始时间但没在 defer 里捕获结束时间，会漏掉耗时和状态码。
- 用
http.ResponseWriter包装器（如responseWriter结构体）拦截WriteHeader和Write，确保能拿到真实status code - 记录字段至少包含：
remote_addr、method、path、status、latency_ms、user_agent（可选）、referer（可选） - 日志输出走
io.Writer接口，不要硬编码到os.Stdout或文件 —— 后续可无缝切到lumberjack.Logger或 Kafka
func loggingMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
start := time.Now()
lw := &loggingResponseWriter{ResponseWriter: w, status: 200}
next.ServeHTTP(lw, r)
log.Printf("%s %s %d %dms %s",
r.RemoteAddr,
r.Method+" "+r.URL.Path,
lw.status,
time.Since(start).Milliseconds(),
r.UserAgent(),
)
})}
日志格式选 JSON 还是文本？优先 JSON
文本日志看着简单，但后续做聚合分析、接入 ELK 或 Loki 时，字段提取极易出错 —— 比如 User-Agent 里含空格或引号，正则一崩全崩。
立即学习“go语言免费学习笔记（深入）”；
JSON 日志天然结构化，且 Go 的 encoding/json 性能足够应付万级 QPS（实测单核 3–5k 条/秒无压力），关键是字段名统一、可嵌套、易扩展。
- 避免用
map[string]interface{}动态拼 JSON，字段顺序不可控，且反射开销大；定义结构体 +json:"field_name"标签更稳 - 敏感字段如
Authorization头、cookie值必须脱敏（置空或哈希），不能原样记录 - 时间字段用
time.Time类型，序列化时指定 RFC3339 或 Unix 毫秒，别用字符串拼接
type AccessLog struct {
Time time.Time `json:"time"`
IP string `json:"ip"`
Method string `json:"method"`
Path string `json:"path"`
Status int `json:"status"`
Latency float64 `json:"latency_ms"`
UserAgent string `json:"user_agent,omitempty"`
}
// 使用示例
logEntry := AccessLog{
Time: time.Now(),
IP: r.RemoteAddr,
Method: r.Method,
Path: r.URL.Path,
Status: lw.status,
Latency: time.Since(start).Seconds() * 1000,
UserAgent: r.UserAgent(),
}
enc := json.NewEncoder(os.Stdout)
enc.Encode(logEntry)
本地文件滚动：用 lumberjack.Logger 而非自实现
自己写文件 rotate 逻辑容易出错：竞态条件导致日志丢失、rename 失败卡死、inode 泄露。社区成熟的 lumberjack 已覆盖所有边界场景。
它不是日志框架，只是一个符合 io.WriteCloser 接口的轮转文件写入器，可直接传给 log.SetOutput 或任何需要 io.Writer 的地方。
-
MaxSize建议设为100（MB），太大难排查，太小频繁切换影响性能 -
MaxBackups控制保留几个历史文件，线上建议7（一周） -
MaxAge是按天清理，和MaxBackups是“或”关系，两个都设更稳妥 - 注意：它不支持按小时切分，如需小时级归档，得配合外部脚本或换用
file-rotatelogs
logWriter := &lumberjack.Logger{
Filename: "/var/log/myapp/access.log",
MaxSize: 100, // MB
MaxBackups: 7,
MaxAge: 7, // days
Compress: true,
}
log.SetOutput(logWriter)高并发下日志写入瓶颈在哪？异步批量刷盘是关键
当 QPS 超过 1k，同步写文件或网络日志服务（如 Loki）会成为瓶颈，表现为 HTTP 延迟陡增、goroutine 积压。根本原因不是磁盘慢，而是每次写都触发系统调用 + 锁竞争。
解决思路不是“更快地写”，而是“少写几次”。用 channel + worker goroutine 批量缓冲日志条目，再统一落盘或发往远端。
- channel 缓冲区大小建议设为
1000–5000，太小易丢日志，太大内存占用高 - worker 每次从 channel 取
min(100, len(ch))条批量处理，兼顾延迟与吞吐 - 务必加
recover防止 worker panic 导致日志静默丢失 - 进程退出前要
close(ch)并等待 worker 清空缓冲，否则最后几条日志会丢
真正复杂的点不在代码，而在权衡：buffer 太大，OOM 风险上升；batch 太大，故障时丢失更多日志；异步后无法保证日志 100% 不丢 —— 如果业务要求强一致性（如支付回调日志），就得退回到同步写 + SSD + 写缓存优化。
