应优先使用 io.readall 或 io.copy：小数据一次性读取用 io.readall，大数据流式传输用 io.copy；手动 for 循环仅适用于流控、限速等特殊场景，且必须先处理 buf[:n] 再判 err。
别手写 for 循环读 io.Reader，90% 的场景用 io.ReadAll 或 io.Copy 就够了。
为什么不能只看 err 就退出循环
网络、TLS、chunked 编码等场景下，Read 常返回 n > 0 且 err == nil，下一次才报错。如果代码写成 if err != nil { break }，会直接丢掉上一轮已读的 buf[:n] 数据。
- 正确顺序永远是：
n, err := r.Read(buf)→ 先处理buf[:n]（只要n > 0）→ 再判断err -
n == 0 && err == nil是非法状态，标准库实现会 panic，不是你漏逻辑，是设计上禁止 -
n > 0 && err == io.EOF合法，表示“这次读到了数据，之后没得读了” -
n == 0 && err == io.EOF也合法，常见于空响应体或空文件
io.ReadAll vs io.Copy：选哪个
两者都内部处理了 io.EOF、分块、错误传播，不用你操心边界逻辑；区别在于语义和内存模型。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 想一次性拿到全部内容（如 JSON 响应、小配置文件）→ 用
io.ReadAll(r)，返回[]byte，再转string(data) - 想把数据从 A 流倒进 B 流（如 HTTP body 转发、文件拷贝）→ 用
io.Copy(dst, src)，它用 32KB 缓冲区，内存占用恒定 -
io.ReadAll会把整个流加载进内存，大文件（>10MB）慎用；io.Copy没这问题 - HTTP 响应体读完不调用
resp.Body.Close()→ 连接无法复用，连接池慢慢耗尽，后续请求变慢甚至超时
什么时候必须手动写 Read 循环
仅适用于流控、限速、逐帧解析、粘包处理等少数需要精确控制读节奏的场景。手动循环不是“更底层”，而是“更危险”——容易漏掉 n 判断、误判 io.EOF、卡在 n == 0 上。
- 每次
Read后必须先用buf[:n]处理有效数据，再根据err决定是否继续 - 自定义
io.Reader时，Read方法必须快速返回，不能做解密、正则、time.Sleep等耗时操作，否则下游如json.Decoder会误判为 IO 卡顿，触发超时 - 测试流式行为（比如模拟网络延迟或分块吐数据），别用
strings.NewReader—— 它是内存全量加载 + 指针偏移，不体现真实 IO 特性；应自己用sync.Mutex+[]byte+int管理剩余数据，每次只取前len(p)字节
缓冲要不要加：用 bufio.Reader 的真实代价
bufio.NewReader 不是“性能优化开关”，而是一个有明确副作用的封装：它会预读、缓存、提前消费数据，可能破坏你对原始 io.Reader 的精确控制。
- 适合频繁读小数据（逐行、逐字节、HTTP header 解析），避免大量系统调用
- 不适合粘包处理、协议头/体分离、或需要与原始连接状态强同步的场景——因为
bufio可能已经把后续几个包的数据读进缓冲区了 - 如果每次读写都是 MB 级大块，
bufio反而增加内存拷贝开销；纯二进制流转发（如文件复制）直接io.Copy就够了 - 记得：用
bufio.Writer必须在关闭前调用Flush()，否则最后一点数据可能滞留在缓冲区里不落盘
最常被忽略的点：自定义 io.Reader 时，Read 方法返回 n == 0 && err == nil 是非法的，但很多人在边界条件（比如数据刚耗尽、锁竞争、chan 关闭）下无意中触发它——Go 运行时会直接 panic，而不是给你 debug 机会。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
