io.writer的write返回(int, error)因可能部分写入，必须检查n==len(buf)，否则易出错；标准库中http.responsewriter、gzip.writer等均实现该接口；io.copy自动处理重试与缓冲，比手动更安全。
为什么 io.Writer 的 Write 方法返回 (int, error) 而不是只返回 error
因为写入可能只完成一部分——比如网络抖动、磁盘满、缓冲区溢出时，Write 会返回已写入字节数和非 nil 错误。忽略返回的 int 值，就等于默认“全写成功”，这是绝大多数 io.Writer 使用错误的根源。
- 必须检查
n, err := w.Write(buf)中的n，确保n == len(buf)；否则要重试或截断处理 -
os.File在部分写入时通常返回io.ErrShortWrite（仅限某些系统），但更常见的是直接返回nil错误 + 小于预期的n - 像
bytes.Buffer这类内存 writer 几乎总能全写成功（n == len(buf)），但代码不能因此省略判断——接口契约不保证这点
哪些类型实现了 io.Writer？别硬猜，用 go doc io.Writer 看
标准库中实现 io.Writer 的类型远不止 os.File 和 bytes.Buffer。真实项目里常被忽略的是：http.ResponseWriter、gzip.Writer、bufio.Writer、io.MultiWriter，甚至 strings.Builder（Go 1.10+）也实现了它。
-
http.ResponseWriter是典型“一次写完就关闭”的场景，调用Write后不能保证数据已发到客户端，但必须确保不 panic 或覆盖 header -
bufio.Writer的Write只写入缓冲区，真正落盘/发包靠Flush()；忘记Flush()是日志不落地、HTTP 响应卡住的常见原因 -
io.MultiWriter把一次Write广播给多个io.Writer，但只要其中一个失败，就立即返回该错误，且不保证其他 writer 写了多少
io.Copy 为什么比手动 Write 更安全？它内部做了什么
io.Copy 不是语法糖，它封装了“读-写-检查-重试”完整循环，专门对抗部分写入和部分读取。手动实现等效逻辑极易漏掉边界条件。
- 它内部用
io.CopyBuffer，默认 32KB 缓冲区，避免小块拷贝放大系统调用开销 - 遇到
io.ErrShortWrite或n 时，自动切片重试剩余部分，你不用管 <code>offset和remaining - 如果目标
io.Writer实现了WriteString且源是string，io.Copy会直接调用它（如bytes.Buffer），跳过 []byte 转换
dst := &bytes.Buffer{}
src := strings.NewReader("hello world")
n, err := io.Copy(dst, src) // 安全，自动处理各种 partial 情况
// 手动等效写法极易出错，不推荐
自定义 io.Writer 时，Write 方法里最常漏掉的三件事
写一个满足接口的 Write 方法，看似简单，但上线后崩溃或丢数据，往往就因为这三点没做。
- 没处理
len(p) == 0：规范要求必须返回n == 0, err == nil，否则io.Copy等工具可能死循环 - 没校验
p是否为nil：虽然文档没强制，但多数标准库实现（如bytes.Buffer.Write）接受nil并返回0, nil；你的实现最好保持一致 - 没考虑并发安全：如果 writer 会被多个 goroutine 同时调用，
Write必须加锁，或者明确文档声明“not safe for concurrent use”
接口本身不带线程安全承诺，这点特别容易被忽略——尤其当底层用到了 sync.Pool 或共享缓冲区时。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
