日志中间件必须置于中间件链末端（Trace→CircuitBreaker→Logging→handler），因其需完整上下文（trace ID、状态码、耗时等）；须用statusRecorder包装ResponseWriter捕获真实状态码与响应大小，并加defer/recover防止panic导致日志丢失。
Go日志中间件不优化，P99延迟就藏在 log.Printf 里。 同步写日志、重复格式化、无缓冲通道、上下文滥用——这些看似“安全”的写法，会在高并发下把请求拖慢 3～5 倍。真正有效的优化不是加功能，而是砍掉阻塞点、复用资源、控制传播路径。
日志中间件为什么一压就慢？
根本原因不是日志本身，而是它在中间件链中被错误地“同步执行”：每次请求都触发一次磁盘 I/O 或格式化操作，goroutine 被卡住，调度器被迫挂起并切换，造成延迟毛刺。某支付网关实测显示，未优化的 LoggingMiddleware 在 2000 QPS 下贡献了 68% 的 P99 延迟。
- 同步调用
log.Printf或fmt.Fprintf→ 阻塞当前 goroutine - 每次请求都新建
time.Time、拼接字符串 → 触发 GC 压力 - 中间件里直接调用
r.Context().Value()取值但没做类型断言保护 → panic 隐患 + 额外反射开销 - 日志内容含敏感字段（如 token、密码）且未脱敏 → 审计风险 + 序列化耗时上升
用带缓冲 channel + 单 goroutine 消费日志
这是最简单也最有效的解耦方式：让日志生成和写入完全分离，主流程只往通道发指针，不等落盘。关键不是“异步”，而是“可控丢弃”和“零分配发送”。
- 通道大小设为
1000（非 100 或 10000）：太小易丢日志，太大内存浪费且背压难控 - 消费 goroutine 必须是单例，避免每请求启一个 → 否则 goroutine 数爆炸，见
/debug/pprof/goroutine - 发送前做
select { case logChan ，通道满就跳过，不阻塞主流程 -
LogEntry结构体字段全用值类型（int64,[16]byte），避免指针逃逸到堆上
中间件里别做日志格式化，交给消费者
格式化是 CPU 密集型操作，放在中间件里等于把所有请求都拖进 fmt 包。应该只采集原始数据，由后台 goroutine 统一处理。
立即学习“go语言免费学习笔记（深入）”；
- 中间件中只记录：
r.Method、r.URL.Path、start.UnixNano()、r.RemoteAddr等原始字段 - 不要调用
time.Now().Format()、fmt.Sprintf、strings.Join—— 这些都在消耗 CPU - 如果必须打结构化日志，用
json.Encoder.Encode()替代json.Marshal()，减少中间 []byte 分配 - 消费端统一做时间格式化、字段映射、脱敏（如正则替换
Authorization头），逻辑集中好维护
context.Value 传日志 ID，但别传日志内容
中间件链需要关联一次请求的所有日志，靠 context.Context 透传 trace ID 是对的；但千万别把日志消息、级别、字段塞进 context —— 这会污染上下文语义，且增加内存占用和 GC 压力。
- 只存轻量标识：
ctx = context.WithValue(r.Context(), logIDKey, uuid.NewString()) - 后续中间件通过
ctx.Value(logIDKey)获取，用于日志 entry 打标，不用于构造日志正文 - 避免用
map[string]interface{}或struct{}当 value，会导致接口底层分配堆内存 - key 类型必须是 unexported struct（如
type logIDKey struct{}），防止外部覆盖
真正卡住性能的，往往不是你没写的逻辑，而是你写了但没想清楚传播路径的那几行日志代码。中间件越薄，链路越稳；日志越懒，系统越快。
