read 方法必须先检查 n 再检查 err：n > 0 时需处理 p[:n]，再依 err 判断后续；常见错误是仅判 err 而丢弃已读数据；推荐优先使用 io.readall 或 io.copy 替代手动循环。
Read 方法必须同时检查 n 和 err，缺一不可
Go 的 io.Reader 不是“读完才返回”，而是“能读多少给多少”。你传一个长度为 4096 的切片，Read 完全可能只填入 12 字节，返回 n = 12、err = nil——这完全合法，且在网络流、chunked HTTP 响应里极其常见。
- 常见错误：写成
if err != nil { break }就退出，结果丢掉已读的p[:n] - 正确顺序永远是：先处理
p[:n]（只要n > 0），再根据err判断后续动作 -
n > 0 && err == io.EOF：正常结束，本次数据有效（比如文件最后一块） -
n == 0 && err == io.EOF：空流，也合法（如空响应体） -
n == 0 && err == nil：非法状态，标准库会 panic，自定义 Reader 绝对不能返回这个组合
别手写 for { n, err := r.Read(buf) } 循环
90% 的场景下，手动循环冗长、易漏逻辑、边界难控。标准库早给你封装好了更安全高效的替代方案。
- 想一次性拿到全部内容（小配置、JSON/YAML 响应）：
io.ReadAll(r)，返回[]byte，直接转string(data) - 想把数据从 A 流复制到 B 流（文件拷贝、HTTP body 转发）：
io.Copy(dst, src)，内部用 32KB 缓冲区，自动处理分块、EOF、错误传播 - 大文件慎用
io.ReadAll：它会把整个流加载进内存；io.Copy是流式，内存占用恒定 - 旧版 Go（ioutil.ReadAll（已弃用），请尽快升级
自定义 Reader 时，Read 方法不能阻塞或耗时
实现 io.Reader 接口 ≠ 写个“带 sleep 的读函数”。它的契约是：每次调用应尽快返回，让调用方控制节奏。
- 在
Read里加time.Sleep、解密、正则匹配，会让json.Decoder或http.Transport误判为 IO 延迟，导致超时、重试甚至死锁 - 需要流式处理（gzip/base64）？用标准包装器：
gzip.NewReader(r)或base64.NewDecoder(enc, r) - 要测慢 Reader？单独写测试类型，但别混进生产逻辑
- 字符串转 Reader？用
strings.NewReader(s)，它只是指针偏移，不分配新内存，性能好
http.Response.Body 读完必须 Close()，重复读要用 bytes.Buffer 缓存
http.Response.Body 是一次性的 io.Reader。读完不 Close()，连接无法复用；想多次读（比如先看 header 再解析 body），它本身不支持 rewind。
- 必须调用
resp.Body.Close()，否则连接池会泄漏 - 需要多次读取？先用
io.ReadAll(resp.Body)拿到完整数据，再用bytes.NewReader(data)创建新 Reader - 或者用
bytes.Buffer缓存：buf := new(bytes.Buffer); io.Copy(buf, resp.Body); buf.Bytes() - 别指望
Seek(0, io.SeekStart)回到开头——除非你明确知道底层实现了io.Seeker（bytes.Reader可以，http.Body不行）
最常被忽略的其实是 n == 0 && err == nil 这个非法组合，以及把 io.EOF 当作普通错误去 panic 或 log.Fatal。它不是 bug，是接口契约的一部分——你写的每个 Read，都在和 io.Copy、json.Decoder 这些上层组件做无声协商。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
