Go 的 io.Reader 和 io.Writer 必须按设计节奏使用：Read 不保证填满缓冲区，返回 n 表示实际读取字节数，需用 buf[:n] 且检查 err；io.Copy 封装了安全的流处理逻辑，避免手写循环的常见错误。
Go 的 io.Reader 和 io.Writer 不是“怎么用”的问题，而是“必须按它设计的节奏来用”——它们不承诺一次读完或写完，也不隐藏 io.EOF，更不帮你管理缓冲区大小。理解这点，就避开了 80% 的流处理 bug。
为什么 Read(p []byte) 返回 n int 而不是直接填满 p？
因为底层数据源（文件、网络、管道）无法保证一次给你想要的全部字节。系统调用可能只返回部分数据，尤其在网络不稳定、磁盘 IO 延迟或小包传输时。Read 的语义是“尽力填，填多少算多少”，而不是“等齐了再给”。
- 常见错误：把
buf := make([]byte, 1024)传给Read后，直接当“已读 1024 字节”处理，忽略返回的n，导致读到脏数据或 panic - 正确做法：永远用
n, err := r.Read(buf)，然后只操作buf[:n] - 遇到
err == io.EOF表示流结束；err != nil && n > 0是“读了一半出错了”，通常要保留已读数据并处理错误
io.Copy 为什么比手写循环更安全？
io.Copy 内部封装了完整的流转发逻辑：自动分配 32KB 缓冲区、循环调用 Read/Write、正确识别 io.EOF、统一错误传播。手写循环极易漏掉边界情况。
- 典型翻车点：自己写
for { n, _ := r.Read(buf); w.Write(buf[:n]) }—— 忽略err导致死循环或静默截断；没检查n == 0可能卡住 -
io.Copy对nil错误零容忍：只要某次Write返回n 且 <code>err != nil，它立刻中止并返回该错误 - 性能上，它避免了小块频繁系统调用；语义上，它明确表达“把 src 全部倒进 dst”，比手动 while 更贴近意图
什么时候该用 bufio.Reader 或 bufio.Writer？
当你频繁读写小数据（比如逐行解析、逐字节处理、HTTP header 解析），原始 Read/Write 会触发大量系统调用，拖慢性能。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
bufio.NewReader(r)在底层 Reader 上加一层内存缓冲，多次Read可能只触发一次系统读；但注意：它会“提前读多一点”，可能影响后续对原始 Reader 的精确控制（如粘包处理） -
bufio.NewWriter(w)把小写合并成大块发出去，减少 write 系统调用；但记得在关闭前调用Flush()，否则最后一点数据可能滞留在缓冲区里不落盘 - 别滥用：如果每次读写都是 MB 级大块，
bufio反而增加内存拷贝开销；纯二进制流转发（如文件复制）直接io.Copy就够了
自定义 Reader 或 Writer 最容易踩的坑是什么？
最常被忽略的是：接口不要求你“一次处理完所有输入”，但你的实现必须严格遵守“部分成功 + 错误可恢复”契约。
- 错误示范：
UpperCaseReader.Read中对每个字节做bytes.ToUpper([]byte{p[i]})[0]—— 这会为单个字节分配新切片，高频调用下 GC 压力陡增；应改用p[i] |= ' '（ASCII 大写转换）或查表 - 必须处理
n == 0 && err == nil：这是合法状态（如空文件、空连接），不能 panic 或跳过 - 不要修改输入切片
p的底层数组以外内容（比如追加、重切），Write方法明确禁止修改p，Read虽未禁止，但破坏 caller 缓冲区预期会导致难以调试的问题
流的本质是“不可靠的连续字节供给”，Go 的 io 接口从不假装它可靠。真正难的不是写对一个 Read 方法，而是让整个数据链路里的每个环节都尊重这个前提——哪怕只是加一行 if n == 0 { continue }，也可能决定服务在线上扛不扛得住突发流量。
