io.Reader 和 io.Writer 仅定义单方法以践行“小而精”接口哲学，确保行为本质明确、组合自然、零抽象开销，并保持与标准库的兼容性。
为什么 io.Reader 和 io.Writer 只定义一个方法？
因为 Go 的接口设计信奉“小而精”——只要能描述行为本质，就不加任何冗余。一个类型只要能 Read([]byte)，它就是 io.Reader；只要能 Write([]byte)，它就是 io.Writer。这种极简定义让组合变得极其自然，比如 bufio.Reader 套在 os.File 上，或 gzip.Writer 包裹 bytes.Buffer，都不需要继承、重写、注册，只要实现那一个方法就行。
常见错误是试图在自定义类型里加 Close() 或 Seek() 到 io.Reader 接口里——这会破坏兼容性，其他函数只认标准接口，不认识你加的扩展方法。
- 别给
io.Reader加额外方法，想关资源就单独调Close()（如果底层支持） - 别用 “我这个 Reader 还能 Seek” 当理由去改接口，需要 seek 就用
io.Seeker，它和io.Reader是正交的 - 性能上，单方法接口零抽象开销，编译器能内联、逃逸分析也更准
Read 方法返回 n, err 的真实含义是什么？
不是“读完才返回”，而是“尽力读，有啥给啥”。n 是本次实际写入 []byte 的字节数，err 才决定是否继续。常见误解是把 n == 0 当成 EOF，其实 n == 0 && err == nil 是合法状态（比如网络空包、管道暂无数据），只有 err == io.EOF 才表示流结束。
典型场景：从 socket 读 HTTP 请求体，可能一次只来几个字节，Read 返回 n=5, err=nil，下一次再读才是剩余部分。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 永远检查
err，不能只看n -
io.ReadFull可以帮你阻塞直到填满 buffer，但要注意它把io.EOF当作错误（除非刚好填满） - 循环读时别写
for n, err := r.Read(buf); n > 0; n, err = r.Read(buf)—— 这漏掉了n==0 && err==nil的情况，也可能在err!=nil时无限循环
什么时候该自己实现 io.Reader？而不是用 bytes.NewReader 或 strings.NewReader
当你需要延迟计算、按需生成、或封装状态机时。比如解析一个分块传输的 API 响应，每调一次 Read 就 fetch 下一块；或者模拟一个不断吐日志行的 reader，内部维护游标和缓冲区。
反例：只是临时把一段 JSON 字符串转成 Reader？直接用 bytes.NewReader(data)，它已经高度优化，且避免了内存分配（底层复用传入切片）。
- 自己实现时，buffer 参数是 caller 提供的，你只能往里写，不能重新分配或返回新切片
- 别在
Read里做耗时同步操作（如磁盘 seek、HTTP 请求），这会让所有依赖它的代码卡住 - 如果底层是异步/流式数据源，考虑用
chan []byte+ goroutine 配合sync.Pool管理 buffer，但注意别让Read阻塞太久
io.Copy 为什么默认用 32KB buffer？换大小会影响什么？
32KB 是实测在多数 Linux 系统上 syscall 开销与内存占用的平衡点。太小（如 1KB）会导致频繁系统调用；太大（如 1MB）可能浪费内存，尤其在并发高、每个 copy 生命周期短的场景（比如代理 thousands of short-lived HTTP requests）。
你可以用 io.CopyBuffer(dst, src, make([]byte, 64*1024)) 显式指定，但得清楚代价：
- buffer 大小不改变语义，只影响吞吐和 GC 压力
- 在容器环境或内存受限设备上，盲目调大 buffer 可能让 RSS 暴涨，触发 OOMKilled
- 某些特殊 writer（如加密 writer）内部有块大小约束，外部 buffer 再大也没用，反而增加拷贝次数
真正难处理的是 reader/writer 两端 buffer 对齐问题——比如一边按 4KB 页读，另一边按 128B 加密块写，这时候光调 buffer 大小没用，得靠中间加 bufio.Writer 缓冲或重写逻辑。
