Go语言实现自定义io.Writer装饰器统计日志流量

io.Writer装饰器不能仅靠嵌入struct实现，因日志库常探测io.Closer、WriteString等接口；必须显式实现Write、Close、WriteString等方法，并用atomic保证并发安全，同时正确处理空写、部分写及panic场景。

为什么 io.Writer 装饰器不能直接套一层 struct 就完事

因为 io.Writer 接口只定义了 Write([]byte) (int, error)，但实际日志库（比如 log.SetOutput 或 zapcore.AddSync）常会检查底层是否实现了 io.Closer、io.StringWriter 甚至 WriteString 方法。如果只嵌入 io.Writer 字段却不透传这些方法，调用方一调用 Close() 就 panic，或者写字符串时退化成 []byte 转换，性能掉一截。

• 必须显式实现所有可能被日志库探测的接口：至少 Write、Close（如果底层支持）、WriteString
• 别用匿名字段“自动提升”——Go 不会自动把嵌入字段的方法提升为当前类型的方法，除非你明确写出来
• 统计逻辑必须放在 Write 和 WriteString 里，否则漏计流量（比如 zap 默认优先走 WriteString）

怎么让装饰器同时统计字节数又不破坏原有行为

核心是把原始 io.Writer 包一层，每次写都先累加长度，再原样转发。但要注意：返回值里的 int 是实际写出字节数，不是你统计的值；出错时也得原样返回错误，不能吞掉。

type CountingWriter struct {
    w     io.Writer
    bytes uint64
}

func (c *CountingWriter) Write(p []byte) (int, error) {
    n, err := c.w.Write(p)
    atomic.AddUint64(&c.bytes, uint64(n))
    return n, err
}

func (c *CountingWriter) WriteString(s string) (int, error) {
    n, err := c.w.WriteString(s)
    atomic.AddUint64(&c.bytes, uint64(n))
    return n, err
}

func (c *CountingWriter) Close() error {
    if closer, ok := c.w.(io.Closer); ok {
        return closer.Close()
    }
    return nil
}

func (c *CountingWriter) Bytes() uint64 {
    return atomic.LoadUint64(&c.bytes)
}

• 用 atomic 是因为日志往往是多 goroutine 并发写的，uint64 非原子读写在 32 位系统上会出错
• 不要在 Write 里做格式化或缓冲——那属于业务逻辑，装饰器只负责“路过计数”
• 如果底层 w 不是 io.Closer，Close() 返回 nil 比 panic 更安全

在 zap / log / slog 里怎么安全注入这个装饰器

不同日志库对 io.Writer 的使用方式不同：标准库 log 只认 Write；zap 会尝试转成 io.Writer 再检查 io.Closer 和 WriteString；slog（Go 1.21+）默认用 slog.NewTextHandler 或 slog.NewJSONHandler，它们内部包装了 io.Writer，但不会主动调用 Close，除非你传的是 *os.File 这类可关对象。

• 给 log.SetOutput：直接传 &CountingWriter{w: os.Stderr} 即可
• 给 zapcore.AddSync：传 zapcore.AddSync(&CountingWriter{w: writer})，确保 writer 本身支持 WriteString（比如 os.Stderr 支持，bytes.Buffer 不支持）
• 给 slog.NewTextHandler：构造 handler 后，它内部会调用 Write，所以装饰器有效；但别指望它调 Close，除非你自己 wrap 的是 *os.File

容易被忽略的边界：空写、部分写、panic 场景

真实日志流里常有 Write([]byte{})（空切片）、网络 writer 返回 n < len(p)（部分写）、甚至底层 writer 在写过程中 panic（比如 pipe 关闭）。装饰器如果没处理好，统计就错，甚至导致整个日志挂死。

• Write([]byte{}) 必须返回 (0, nil)，且不增加计数——否则空日志也会涨字节数
• 部分写场景下，只累加 n，不是 len(p)；否则高估流量
• 如果底层 Write panic，装饰器不能 recover——日志库需要知道失败，强行 recover 会导致错误静默
• 别在 Bytes() 方法里加锁，用 atomic.LoadUint64 就够；但如果你要重置计数，就得用 atomic.StoreUint64，别用赋值

统计本身很简单，难的是和各种日志库的接口博弈——它想调什么方法、什么时候调、调了不实现会怎样，这些细节不摸清，装饰器要么不工作，要么偷偷吃掉错误或统计失真。