io.reader 的 read 方法必须同时检查 n 和 err：先处理 p[:n]（n>0 时），再根据 err 判断状态；优先使用 io.readall 或 io.copy，避免手动循环；自定义 reader 不得阻塞；http body 需 close 并缓存复用。
io.Reader 的 Read 方法必须检查 n 和 err 两个返回值
Go 的 io.Reader 不是“读完才返回”，而是“能读多少给多少”。你传入一个长度为 1024 的切片 p，Read(p) 完全可能只填进去 3 字节，然后返回 n=3, err=nil——这完全合法，且常见于网络流、chunked HTTP 响应或慢设备。
- 常见错误：写成
if err != nil { break }就退出，结果丢掉已读的p[:n]数据 - 正确模式永远是：先处理
p[:n]（只要n > 0），再判断err -
err == io.EOF且n > 0：正常结束，本次数据有效 -
n == 0且err == io.EOF：空流，比如空文件或空 HTTP body，也合法 -
n == 0且err == nil：非法状态，标准库会 panic，别自己造这种 Reader
别手写循环读取，优先用 io.ReadAll 或 io.Copy
90% 的场景下，你不需要手动写 for { n, err := r.Read(buf) }。它冗长、易漏逻辑、还容易在边界上出错。标准库已经封装好了更安全、更高效的替代方案。
- 想一次性拿到全部内容（如解析 JSON/YAML/小配置）：用
io.ReadAll(r)，返回[]byte，再转string即可 - 想把数据从 A 流复制到 B 流（如文件拷贝、HTTP body 转发）：直接
io.Copy(dst, src)，它内部用 32KB 缓冲区，自动处理分块、EOF、错误传播 - 手动循环只在特殊场景需要：比如限速读取、逐帧解码、或模拟延迟测试
- 注意：
io.ReadAll会把整个流加载进内存，大文件慎用；io.Copy是流式，内存占用恒定
自定义 Reader 时，别在 Read 里做阻塞或耗时操作
实现 io.Reader 接口不等于“写个读文件函数”。它的契约是：每次调用 Read(p) 应尽快返回，让调用方控制节奏。如果你在 Read 里加了 time.Sleep、正则匹配、或解密计算，下游的 json.Decoder 或 http.Transport 会误判为 IO 延迟，导致超时、重试或死锁。
- 真实 IO 延迟应由底层资源（如 net.Conn）负责，你的 Reader 只做“桥接”或“转换”
- 需要流式解码（如 base64、gzip）？用标准库包装器：
base64.NewDecoder(enc, r)或gzip.NewReader(r) - 要测试慢 Reader？单独写个带
time.Sleep的测试类型，但别混进生产逻辑 - 字符串转 Reader？用
strings.NewReader(s)，它只是指针偏移，不分配新内存，性能好
HTTP Body 读完必须 Close，重复读要用 bytes.Buffer 缓存
http.Response.Body 是一次性的 io.Reader。读完不 Close() 会导致连接无法复用；想多次读（比如先看 header 再解析 body），它本身不支持 rewind，必须自己缓存。
- 读完立刻调用
resp.Body.Close()，否则连接池会泄漏 - 需要多次读？用
io.Copy先写进bytes.Buffer，再用buf.Bytes()或buf.Reader()构造新 Reader - 别用
strings.NewReader(string(buf.Bytes()))处理大响应——字符串转换会多一次内存拷贝 - 如果只是检查 content-type 或 status-code，别急着读 body；很多中间件（如
httputil.DumpResponse）会帮你做缓冲
最常被忽略的其实是那个 n == 0 && err == nil 的非法状态——不是你忘了写逻辑，而是 Go 明确禁止这种“无进展也不报错”的行为。一旦出现，一定是底层 Reader 实现错了，或者你误把未初始化的 struct 当作了 Reader。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
