go中实现带日志/校验/限速的io.writer装饰器需显式实现write、writestring、close等接口，用atomic保证并发安全，并严格透传返回值与错误；countingwriter示例中先调用底层write再累加字节数，暴露bytes()方法供读取。
如何用 Go 实现带日志/校验/限速的 io.Writer 装饰器
Go 的 io.Writer 接口极其简洁（仅一个 Write([]byte) (int, error) 方法），这恰恰让它成为装饰器模式的理想载体。你不需要改写底层文件操作，只需包装一层，就能在写入前/后插入逻辑——比如记录字节数、计算 CRC32、打日志、或控制写入速率。
关键点在于：装饰器本身也实现 io.Writer，内部持有一个被包装的 io.Writer（如 *os.File 或 bufio.Writer），所有 Write 调用都经过它中转处理。
写一个带实时字节计数的 CountingWriter
这是最典型的装饰器场景：你想知道往文件里写了多少字节，又不想每次手动累加。直接封装比在业务层反复调用 len(data) 更可靠（尤其当底层有缓冲时）。
常见错误是忽略 Write 返回值中的实际写入长度（n），只看 error。装饰器必须严格返回底层 Write 的 n 和 err，否则上层逻辑（比如 io.Copy）会出错。
- 定义结构体：
type CountingWriter struct { w io.Writer; n int64 } -
Write方法里先调用w.Write(p)，再更新c.n += int64(n) - 暴露
Count()方法供外部读取，不要暴露n字段（避免竞态） - 如果要并发安全，用
sync/atomic.AddInt64(&c.n, int64(n))替代普通加法
func (c *CountingWriter) Write(p []byte) (n int, err error) {
n, err = c.w.Write(p)
atomic.AddInt64(&c.n, int64(n))
return
}
组合多个装饰器时为什么顺序很重要
Go 没有内置装饰器链语法，你得手动嵌套：比如 LimitWriter(HashWriter(FileWriter))。这时执行顺序是从外到内，而数据流是“进→装饰器1→装饰器2→底层 Writer”，所以每个装饰器看到的 []byte 内容可能已被前序修改。
典型陷阱：
- 把
HashWriter放在LimitWriter外面 → 哈希计算的是被截断后的数据，不是原始输入 - 把
LoggingWriter放在BufferedWriter外面 → 日志里打印的是每次Write调用的原始切片，但实际刷盘是批量的，日志和磁盘内容不一致 - 所有装饰器都该假设输入
p是只读的；若需修改（如加前缀），必须拷贝：buf := append([]byte("prefix"), p...)
文件扩展名与装饰器无关，但影响底层 os.OpenFile 行为
标题里提到“文件扩展”，这里需要厘清：装饰器工作在 io.Writer 接口层，完全不感知路径、扩展名或文件系统语义。真正决定文件行为的是打开方式（os.O_CREATE | os.O_WRONLY | os.O_APPEND）和权限（0644）。
容易被忽略的点：
- 扩展名不会自动触发 MIME 类型处理或编码转换；那是应用层责任（比如你写
.json文件，仍需自己调用json.Encoder.Encode()） - 如果要用
gzip.Writer压缩写入，它本身就是一个标准装饰器，但你得确保文件扩展名（如.gz）和解压逻辑匹配，否则用户双击打不开 - Windows 下某些扩展名（如
.exe）受系统策略限制，装饰器无法绕过 —— 错误发生在os.OpenFile阶段，而非Write时
装饰器解决的是“怎么写”，不是“写成什么文件”。扩展名只是约定，真正的约束来自操作系统和你的使用意图。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
