io.Writer 接口未初始化即为 nil，调用 Write 会 panic；必须绑定具体实现（如 os.Stdout）；Write 必须返回真实写入字节数和错误；网络写入应使用 bufio.Writer 缓冲并显式 Flush；io.Copy 比手写循环更安全可靠。
io.Writer 是个接口，不是具体类型，直接声明不赋值就会 panic
你写 var w io.Writer，它就是 nil，不是“空但可用”，而是根本不能调用 Write 方法——运行时直接报 invalid memory address or nil pointer dereference。
- 原因：Go 的接口变量由 type 和 value 两部分组成；未初始化时二者均为
nil，调用方法等于对空指针解引用 - 正确做法：必须绑定一个实际实现了
Write方法的实例，比如os.Stdout、bytes.Buffer{}、net.Conn，或自己写的结构体 - 常见误写：
io.WriteString(w, "x")在w为nil时照样 panic，错误检查if err != nil根本来不及触发
Write 方法必须严格返回真实写入字节数，不能硬写 len(p)
Write(p []byte) (n int, err error) 的 n 不是“应该写多少”，而是“这次真的写进去几个字节”。网络断开、磁盘满、缓冲区卡住……任何中间出错，都得立刻返回当前已写数量和错误，不能攒着、不能吞掉、不能补足。
- 典型错误：实现自定义
Writer时写成return len(p), nil—— 这违反契约，上游逻辑（如io.Copy）会误判传输完成，导致数据截断或死锁 - 真实场景：TCP 连接写入时可能只发出前 32 字节就因对端关闭而失败，此时必须返回
n=32, err=io.ErrClosedPipe，而不是继续尝试或静默丢弃 - 安全做法：所有包装器（如
bufio.Writer）内部都检查每次底层Write返回的n，并累积/重试/截断，你封装时也得照做
网络写入别裸调 conn.Write，小数据高频写务必套 bufio.Writer
直接对 net.Conn 调 Write 每次都是一次系统调用，发 100 条短消息 = 100 次 syscall，性能断崖式下跌。
- 用法：传
conn给bufio.NewWriter，之后所有WriteString/Write都进内存缓冲，最后必须显式调Flush()才真正发出去 - 陷阱：
defer writer.Flush()很危险——如果程序提前 panic 或 return，Flush可能没执行，数据就丢了；更稳妥的是在关键路径结尾主动if err := writer.Flush(); err != nil { ... } - 注意：
bufio.Writer的缓冲区大小默认 4KB，写入超量会自动 flush，但别依赖这个行为来规避手动Flush，尤其在连接要关闭前
io.Copy 是最安全的流转发方式，别手写 Read/Write 循环
自己写 for 循环读一块、写一块，看似可控，实则极易漏掉 n == 0 判断、误把 io.EOF 当真错误、忽略部分写入后需重试等边界情况。
立即学习“go语言免费学习笔记（深入）”；
-
io.Copy(dst, src)内部用 32KB 缓冲区，自动处理Read返回n 、<code>Write返回n 、遇到 <code>io.EOF时优雅退出，还统一返回总字节数和最终错误 - 适用场景极广：文件到文件、网络到文件、
bytes.Reader到http.ResponseWriter、甚至加密流链式转发（只要上下游都满足Reader/Writer） - 限制长度？用
io.LimitReader(src, n)包一层再喂给io.Copy；边读边记日志？用io.TeeReader(src, logger)
最容易被忽略的点是：Write 的语义不是“确保写完”，而是“尽力写一批”，哪怕只写了一半也得如实汇报。这决定了所有基于它的上层逻辑（包括 io.Copy、json.Encoder、http.Server）都必须按部分成功来设计，而不是假设原子性。
