io.reader 和 io.writer 仅定义单方法，体现 go“小而精”接口哲学：read([]byte) 和 write([]byte) 分别精准刻画读写本质，支持无缝组合、零抽象开销、清晰语义（n 表示实际字节数，err 才标志结束），并避免污染接口。
为什么 io.Reader 和 io.Writer 都只定义一个方法？
因为 Go 的接口哲学是“小而精”——只要能准确描述行为本质，就不加任何冗余。一个类型只要能 Read([]byte)，它就是 io.Reader；只要能 Write([]byte)，它就是 io.Writer。这种设计让组合天然成立，比如 bufio.NewReader 套在 *os.File 上，或 gzip.NewWriter 包裹 bytes.Buffer，都不需要继承、重写、注册。
- 别给
io.Reader加Close()或Seek()—— 这会破坏与其他函数的兼容性，它们只认标准接口 - 想关资源？单独调用底层类型的
Close()（如果支持）；需要定位？用正交的io.Seeker - 单方法接口没有抽象开销：编译器能内联，逃逸分析更准，性能不打折
Read(p []byte) 返回 n, err 到底意味着什么？
它不是“读完才返回”，而是“尽力读，有啥给啥”。n 是本次实际写入 p 的字节数，err 才决定是否继续。常见误解是把 n == 0 当成 EOF，其实 n == 0 && err == nil 是合法状态（比如网络空包、管道暂无数据），只有 err == io.EOF 才表示流结束。
- 永远检查
err，不能只看n - 别写
for n, err := r.Read(buf); n > 0; ...—— 漏掉n==0 && err==nil，也可能在err!=nil时无限循环 - 需要填满缓冲区？用
io.ReadFull，但它把刚好读到 EOF 且未填满视为错误
什么时候该自己实现 io.Reader，而不是用 bytes.NewReader？
当你需要延迟计算、按需生成、或封装状态机时才值得手写。比如每调一次 Read 就 fetch 一块分块响应，或模拟一个不断吐日志行的 reader，内部维护游标和缓冲区。
- 反例：只是临时把一段 JSON 字符串转成 Reader？直接用
bytes.NewReader(data)—— 它已高度优化，且复用传入切片，避免额外分配 - 自己实现时，
p []byte是调用方提供的，你只能往里写，不能重新分配或返回新切片 - 别在
Read里做耗时同步操作（如磁盘 seek、HTTP 请求），否则所有依赖它的代码都会卡住
用 io.Copy 代替手动读写循环，不只是为了省代码
io.Copy(dst, src) 不仅简洁，还内置了 32KB 缓冲区、自动处理短读/短写、正确传播 io.EOF 和其他错误，是流式转发最安全高效的方式。手动循环容易漏边界、错判 EOF、忽略部分写入，尤其在网络或管道场景下更明显。
- 文件复制：
io.Copy(dst, src)比自己建[]byte循环快且稳 - HTTP 响应体转发：
io.Copy(w, req.Body)直接复用，无需解码或中间字符串 - 注意：包装型
Writer（如bufio.Writer）必须显式Flush()，否则缓冲内容可能丢失
最常被忽略的其实是 n == 0 && err == nil 这个状态——它合法、常见、且不表示结束，但很多逻辑会把它当成死循环入口或提前退出条件。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
