io.Writer接口仅含Write([]byte) (int, error)方法，要求返回实际写入字节数并及时上报错误；正确实现需处理部分写入、提供Flush、避免Write中调用Flush，并优先使用io.WriteString而非手动转换字符串。
Writer 接口定义和核心要求
io.Writer 是 Go 标准库中最基础的写入接口，只含一个方法：Write([]byte) (int, error)。它不关心数据去哪、是否缓存、是否阻塞，只承诺：把给定字节切片尽可能写进去，并返回实际写入长度和可能的错误。
实现时必须注意两点：一是返回值 int 必须是「已写入字节数」，不能硬写 len(p)；二是只要写入中途出错（比如磁盘满、连接断开），就得立刻返回错误，不能吞掉或延迟上报。
- 常见错误：自定义
Write方法里忽略部分写入失败，仍返回len(p)，导致上层误判写入成功 - 典型场景：日志写入器、网络流封装、内存缓冲写入器都依赖这个契约
- 性能影响：如果每次
Write都直接落盘或发包，会极慢；通常需配合bufio.Writer批量处理
如何正确实现一个带缓冲的 Writer
直接实现 Write 容易踩坑，更推荐组合已有类型。例如用 bufio.Writer 包裹底层 io.Writer，再暴露自己的写入逻辑：
type MyLogger struct {
bw *bufio.Writer
}
func (l *MyLogger) Write(p []byte) (n int, err error) {
// 加前缀、时间戳等处理
line := append([]byte("[INFO] "), p...)
line = append(line, '\n')
return l.bw.Write(line)
}
func (l *MyLogger) Flush() error {
return l.bw.Flush()
}
关键点在于：自己不管理缓冲区，而是复用 bufio.Writer 的缓冲与刷新逻辑；Flush 必须显式提供，否则缓冲内容可能永不写出。
立即学习“go语言免费学习笔记（深入）”；
- 别在
Write里调bw.Flush()—— 会彻底失去缓冲意义 - 如果底层 Writer 不支持部分写入（如
os.Stdout），bufio.Writer.Write仍可能返回n < len(p)，你的实现也要透传这个行为 - 所有基于
io.Writer的封装，都应允许使用者调用Flush或关闭资源
Write 实现中容易被忽略的边界情况
真实环境里，Write 可能返回 n == 0 且 err == nil（比如管道写端已关闭但未报错），也可能返回 n < len(p) 且 err == nil（比如 socket 发送缓冲区满）。标准库中绝大多数函数（如 fmt.Fprint、json.Encoder.Encode）都依赖正确处理这些情况。
- 不要假设
Write一定写完全部字节；循环写入需检查n并偏移切片：p = p[n:] - 不要把
err == nil当作「写完了」，而应以n是否等于输入长度为准 - 测试时用
bytes.Buffer做底层 Writer 很方便，但它永远不会返回n < len(p)，需额外构造场景验证部分写入逻辑
为什么 io.WriteString 比 w.Write([]byte(s)) 更安全
io.WriteString 是标准库提供的快捷函数，内部做了两件事：一是避免临时分配 []byte（Go 1.19+ 对小字符串做了优化），二是正确处理 string 到 []byte 的转换，不触发逃逸。
而手动写 w.Write([]byte(s)) 在多数情况下会强制分配底层数组，尤其当 s 来自函数参数或变量时。更隐蔽的问题是：如果 w 是自定义类型且 Write 方法有副作用（比如计数、加锁），两次调用（一次转切片、一次写入）可能破坏原子性。
- 优先用
io.WriteString(w, s)，除非你明确需要操作原始字节切片 - 如果必须用
[]byte，考虑复用sync.Pool缓冲切片，但要注意数据竞争 - 对高频写入场景（如 HTTP 响应体），
io.WriteString的零分配优势在 pprof 中可明显观测到
n 和 error 的组合含义；接口简单，但每个返回值都在传递状态。 
