Go 的 io 包仅定义接口，不实现文件操作；io.Copy 卡住因源未返回 io.EOF；ReadFull 要求填满缓冲区，ReadAtLeast 只需满足最小字节数；ReadAll 易致 OOM，应限长或流式处理。
Go 的 io 包本身不直接提供“打开文件”或“读写磁盘”的能力，它只定义统一的数据流接口（io.Reader、io.Writer 等），真正干活的是 os、bytes、strings 这些包提供的具体实现。搞不清这点，很容易在调用时卡在类型不匹配或空指针 panic 上。
为什么 io.Copy 有时卡住或返回 0, nil
这是最常被忽略的典型问题：io.Copy 会一直读到源 Reader 返回 io.EOF 才停止。如果源不是有限流（比如没关闭的管道、未设超时的网络连接、或自己写的 Reader 忘了在末尾返回 io.EOF），它就永远阻塞。
- 检查源是否明确支持 EOF：文件、
bytes.Buffer、strings.Reader都没问题；自定义Reader必须在数据耗尽后返回(0, io.EOF) - 网络场景下，务必设置
conn.SetReadDeadline，否则io.Copy可能挂起数分钟 - 调试时加一行：
n, err := io.Copy(dst, src); fmt.Printf("copied %d bytes, err: %v\n", n, err)—— 很多时候err == nil但n == 0就说明源一开始就是空或已 EOF
io.ReadFull 和 io.ReadAtLeast 的边界行为差异
这两个函数都用于确保读取“足够多”的字节，但失败条件完全不同，选错会导致逻辑 bug。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
io.ReadFull(r, buf)：要求**必须填满整个buf**，少一个字节就算失败，返回io.ErrUnexpectedEOF -
io.ReadAtLeast(r, buf, min)：只要读到 ≥min字节就成功，哪怕buf没填满；如果最终读不到min字节，才返回io.ErrShortBuffer - 典型误用：用
ReadFull读 HTTP 响应体，但服务端可能分 chunk 发送，导致提前失败；此时该用io.ReadAll或循环Read
如何安全地把 io.Reader 转成字符串而不爆内存
直接用 io.ReadAll 读任意 Reader 是高危操作——如果源是无限流（如 os.Stdin 未设 EOF）或超大文件，程序会 OOM。
立即学习“go语言免费学习笔记（深入）”；
- 优先考虑流式处理：用
bufio.Scanner按行读，或bufio.Reader.ReadBytes('\n')分块处理 - 必须转字符串时，加长度限制：
io.LimitReader(r, 10（限制 10MB），再传给 <code>io.ReadAll - 注意
strings.NewReader和bytes.NewReader返回的是可重复读的Reader，而文件或网络Reader一般不可重放 —— 别指望读完还能 rewind
真正难的不是记住函数名，而是判断哪个接口组合能守住资源边界：什么时候该用 io.LimitReader，什么时候该换 bufio.Reader 做缓冲，以及为什么 io.MultiReader 里任何一个子 Reader 返回非 EOF 错误就会立即中断整个链。这些细节不踩几次坑很难有体感。
