go的io接口带error返回值是为显式暴露边界情况，read/write均返回实际字节数与错误，调用方需处理eof、短写等；自定义类型须符合行为契约而非仅签名；multireader/multiwriter是顺序接力非并行；io.copy默认32kb缓冲区是性能权衡。
为什么 io.Reader 和 io.Writer 的方法签名都带 error 返回值
因为 Go 的 IO 操作默认不假设成功——哪怕只是从内存切片读一个字节，也得考虑 EOF 是否已到、缓冲区是否被意外截断。这不是过度防御，而是把“边界情况”直接暴露在类型契约里。Read 和 Write 都只承诺“尽力而为”，返回实际处理的字节数 + 可能的错误，由调用方决定下一步：是重试、忽略、还是终止。
常见错误现象：Read 返回 n == 0 && err == nil（非法状态，应 panic 或修复底层实现）；或忽略 err == io.EOF 导致死循环读取。
-
Read必须在遇到EOF时返回err == io.EOF，不能只靠n == 0判断结束 -
Write允许写入少于请求长度（比如网络缓冲区满），但必须返回真实写入数，调用方需自行补全 - 所有标准库实现（
bytes.Reader、os.File、net.Conn）都严格遵循这一契约，跨包组合才不会出错
如何判断一个自定义类型是否真正实现了 io.Reader
不能只看有没有 Read([]byte) (int, error) 方法——签名对了，行为不对照样崩。核心是验证它是否尊重 io.Reader 的隐含协议：可重复调用、不隐式修改输入切片、对空切片 buf 返回 n == 0, err == nil（除非 EOF 已到）。
使用场景：写单元测试时，别只测“能编译”，要测 io.Copy 能否安全消费你的类型。
立即学习“go语言免费学习笔记（深入）”；
- 用
io.Copy(ioutil.Discard, yourReader)触发完整生命周期，观察是否 panic 或卡住 - 传入长度为 0 的
[]byte，检查是否返回(0, nil)（非 EOF 场景下） - 如果内部缓存依赖指针或共享底层数组，注意
Read后不要让调用方误以为数据还“活着”——Go 不保证切片内容在Read返回后仍有效
io.MultiReader 和 io.MultiWriter 的真实用途不是“合并”，而是“顺序接力”
它们名字容易误导：不是把多个 Reader 并行读取拼起来，而是按顺序读完第一个，再读第二个，以此类推；MultiWriter 则是把同一份数据同步写进所有目标。性能上无并发优化，纯线性控制流。
参数差异：MultiReader 接收 ...io.Reader，但一旦某个 Reader 返回 io.EOF，就立即切换下一个；MultiWriter 对每个 Write 调用，会逐个调用所有 writer 的 Write，任一失败即整体失败（返回首个错误）。
- 典型误用：拿
MultiReader当“并行读取器”——它不提升吞吐，反而增加调度开销 - 适合场景：日志写入（同时写文件 + 网络 + 内存缓冲）、配置加载（先查 env，再读 config.json，最后 fallback 默认值）
- 注意
MultiWriter的错误传播逻辑：只要第一个Write成功，后续 writer 即使失败，数据也已部分落盘，无法回滚
为什么 io.Copy 默认用 32KB 缓冲区，而不是更大或更小
这是实测权衡：太小（如 1KB）导致系统调用频繁，CPU 花在上下文切换上；太大（如 1MB）浪费内存且对小文件无益，还可能阻塞 goroutine 更久。32KB 在 Linux 默认页大小（4KB）和 ext4 块大小之间取得平衡，适配大多数磁盘与网络栈。
性能影响：如果你明确知道数据源是 mmap 文件或高速内存通道，可以手动用 io.CopyBuffer 指定更大缓冲区；但对 HTTP body 或管道，盲目调大反而降低响应及时性。
-
io.Copy内部不保证原子性：一次Read+ 一次Write构成一个单元，中途出错则已写入部分不可逆 - 若需精确控制缓冲区，用
io.CopyBuffer(dst, src, make([]byte, 64*1024))，但别用全局复用的切片——CopyBuffer不保证不修改它 - 在低内存环境（如嵌入式 Go），可降为 8KB，但需实测确认 syscall 开销未反超
接口设计上最易被忽略的一点：所有 io 接口都不持有数据所有权，也不约定生命周期。你传进去的 []byte、io.Reader、甚至 context.Context，都得自己管好何时释放、是否并发安全。Go 把“谁负责”划得极清，也意味着没人替你兜底。
