io.writer变量未初始化即写入会panic；write不保证一次写完，需检查n和err并重试；二进制数据禁用io.writestring；net.conn建议用bufio.writer包装并flush；write语义统一但底层行为差异大。
io.Writer 变量声明后直接写入会 panic
声明 var w io.Writer 后不赋值就调用 io.WriteString 或 w.Write，程序会在运行时崩溃：panic: runtime error: invalid memory address or nil pointer dereference。这不是编译错误，容易漏测。
- 接口变量的零值是
nil，和var p *int初始为nil一样，不能直接解引用 -
io.WriteString内部会调用w.Write([]byte(s))，一旦w是nil，就触发空指针解引用 - 必须显式初始化：比如
w = os.Stdout、w = &bytes.Buffer{}、w = file
Write 方法返回的 int 不等于 len(p) 是正常现象
Write 不保证一次写完全部字节——尤其在网络连接、管道或磁盘满时，可能只写入部分数据就返回错误或提前结束。硬写 if n != len(p) { ... } 报错，反而会让程序在真实生产环境中频繁失败。
- 必须检查返回值
n和err，但逻辑要分情况：若n > 0 && err == nil，说明部分成功，需重试剩余部分 - 若
err != nil（如io.ErrShortWrite或连接中断），应立即处理，不能忽略 - 高频小写场景建议用
bufio.Writer包装，它内部自动重试并聚合写入，但记得最后调用Flush()
二进制数据别用 io.WriteString
io.WriteString 内部把字符串转成 []byte，而 Go 中 string 是只读 UTF-8 序列，无法安全表示含 \x00、\xFF 或非 UTF-8 字节的原始二进制数据。转换过程可能被截断、污染，甚至在 CGO 边界引发未定义行为。
- 写二进制一律用
Write([]byte{...})或binary.Write(w, endian, value) - 结构体写入优先走
encoding/binary，它按指定字节序序列化，字段顺序即二进制布局，不加 padding - 反例：
io.WriteString(w, string([]byte{0x00, 0xFF}))—— 危险；正例：w.Write([]byte{0x00, 0xFF})
net.Conn 能直接当 io.Writer 用，但别忘了缓冲与刷新
net.Conn 天然实现 io.Writer，所以 conn.Write([]byte("msg")) 是合法的。但每次调用都是一次系统调用，小数据频繁发包效率极低，还可能因 TCP Nagle 算法导致延迟。
- 推荐用
bufio.NewWriter(conn)包装，批量攒数据再发；但必须在关键路径末尾显式调用writer.Flush() - 忘记
Flush()是最常见线上问题之一：连接看似“发了”，实际卡在缓冲区里没出去 - 如果需要严格控制每条消息边界（如协议头+body），缓冲器反而增加复杂度，此时宁可不用
bufio，改用手动拼包 + 全量Write并校验n
最常被忽略的一点：所有实现了 io.Writer 的类型，其 Write 方法语义完全一致，但底层行为天差地别——文件写入可能阻塞数毫秒，网络写入可能超时，内存 buffer 几乎瞬时完成。写通用代码时，永远假设 Write 可能部分成功、可能延迟、可能失败，别依赖“一次到位”的幻觉。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
