日志中间件压测拖垮服务的根本原因是同步阻塞、未复用资源和错误调用时机；应异步写入、全局复用文件句柄、用statusRecorder捕获状态码、避免锁竞争与频繁系统调用。
为什么日志中间件一压测就拖垮服务
根本原因不是“写得太慢”，而是同步阻塞 + 未复用资源 + 错误的调用时机。标准库 log.Printf 或直接 fmt.Fprintf(os.Stderr, ...) 在高并发下会争抢 stdout 的锁，且每次写都触发系统调用；若中间件里还反复 os.OpenFile，too many open files 几乎必然出现。
- 避免在中间件内调用
log.SetOutput(file)—— 它内部有全局互斥锁，实测吞吐下降 15%～20% - 绝不要在每次请求中
os.OpenFile("access.log", ...)，必须提前一次打开、全局复用*os.File - 状态码不能从
r或原始w读取，必须用statusRecorder包装http.ResponseWriter后捕获 - 时间戳别用
time.Now().Format("2006-01-02T15:04:05")，改用time.Now().UnixMicro()，省掉字符串拼接开销
如何让日志不丢、不错、不卡住 goroutine
核心是分离「日志构造」和「日志写入」：中间件只负责提取字段、组装结构体；真正 I/O 交给异步 worker 或缓冲池，确保即使磁盘满、pipe 断开，也不影响 HTTP 响应流程。
- 用
zap.Logger.With(zap.String("request_id", reqID))构造带上下文的 logger 实例，而非每次拼接字符串 - 若坚持用标准库，至少把
fmt.Fprintf(file, ...)改为file.Write(...)+ 预分配[]byte，减少内存分配 - 大流量场景下禁用
file.Sync()，接受几秒延迟；轮转交给logrotate，中间件自己切文件易出竞态 - 路径务必用绝对路径，比如
/var/log/myapp/access.log，避免 systemd 或容器启动时工作目录变动导致写入失败
panic 导致日志中断怎么办
业务 handler panic 后，next.ServeHTTP() 后的代码不会执行，你看到的可能是半截日志、甚至完全没记录。recover 必须加在最外层，且要补响应、记堆栈、防二次 panic。
- 中间件开头加
defer func() { if r := recover(); r != nil { /* 记录完整堆栈 */ debug.PrintStack() /* 补 500 响应 */ w.WriteHeader(500) } }() - 别用
err.Error()打印 panic，用fmt.Printf("%+v", r)或debug.PrintStack()，否则丢失调用链 - 如果用了异步日志（如 goroutine 写 zap），recover 只能捕获当前 goroutine 的 panic，异步逻辑需单独封装带 recover 的 worker
-
c.Abort()（Gin）或显式return（原生 net/http）必须紧跟 recover 后，防止控制流继续向下执行已失效的 handler
JSON 日志中文变 \u4f60\u597d 怎么办
这不是 bug，是 json.Marshal 默认对非 ASCII 字符做 Unicode 转义。查日志时得复制粘贴再解码，线上排查效率极低。
立即学习“go语言免费学习笔记（深入）”；
- 用
json.Encoder替代json.Marshal，调用enc.SetEscapeHTML(false)（仅去 HTML 转义），但 Unicode 仍保留 - 要彻底禁用 Unicode 转义，得用
go-json库或自定义MergeMap+json.RawMessage拼接 - 字段值别加
json:",string"标签，否则数字被引号包住，ES/Kibana 会当 keyword 类型解析失败 - 更轻量方案：用
zap.Stringer+ 自定义String()方法，比 JSON 序列化快得多，且天然不转义
关键点往往藏在细节里：statusRecorder 的 Write 方法里漏判 r.status == 0，会导致所有未显式调用 WriteHeader 的 handler 状态码记成 0；request_id fallback 逻辑若依赖 time.Now().String()，在高并发下可能重复——这些都不是理论问题，是线上真实崩过三次的坑。
