Go 的 io 标准库提供统一接口抽象（如 io.Reader、io.Writer）而非直接文件操作；io.ReadFull 要求填满切片，不足则返回 io.ErrUnexpectedEOF；io.Copy 拷贝至 EOF，io.CopyN 必须拷贝恰好 n 字节；安全转字符串应优先流式处理，不可信输入需用 io.LimitReader 限长。

Go 的 io 标准库不是用来“直接读写文件”或“格式化输入”的，而是提供一套统一的接口抽象（如 io.Reader、io.Writer），让不同数据源/目标能用相同方式组合和复用。

为什么 io.ReadFull 有时返回 io.ErrUnexpectedEOF 而不是 io.EOF

这是最常被误解的行为之一。io.ReadFull 要求「必须填满整个切片」，只要没读够就报错；而 io.Read 只要读到一点数据就返回成功（哪怕只剩几个字节）。

• io.ReadFull 适合解析固定长度协议头（比如前 4 字节是包长度），失败即中断流程
• 如果底层 Reader 实际只有 2 字节可读，但你传了长度为 8 的 []byte，就会触发 io.ErrUnexpectedEOF
• 注意：

  

  io.EOF 是合法结束信号，io.ErrUnexpectedEOF 表示“本该还有但没了”，属于异常

io.Copy 和 io.CopyN 在处理网络流时的关键区别

它们都用于高效字节搬运，但对“完成条件”的定义完全不同。

• io.Copy(dst, src)：一直拷贝直到 src 返回 io.EOF 或其他错误
• io.CopyN(dst, src, n)：只拷贝恰好 n 字节，即使 src 提前 EOF 也会报 io.ErrUnexpectedEOF
• HTTP body 流式读取时，若用 CopyN 限制大小防攻击，记得捕获 io.ErrUnexpectedEOF —— 它可能意味着客户端提前断开，而非恶意超长
• 两者内部都使用 32KB 缓冲区，无需手动优化缓冲大小

如何安全地把 io.Reader 转成字符串而不爆内存

别直接用 io.ReadAll 处理不可信输入（比如用户上传的文件流），它会把全部内容加载进内存。

• 优先考虑流式处理：scanner := bufio.NewScanner(r); for scanner.Scan() { process(scanner.Text()) }
• 如果真需要完整字符串且信任数据源，用 io.ReadAll 即可，但它没有长度限制
• 若需带限长保护，自己封装：用 io.LimitReader(r, maxLen) 包一层再传给 io.ReadAll，超出部分会被截断并返回 io.EOF
• strings.NewReader 是构造 io.Reader 的快捷方式，仅用于测试或小量数据

真正难的从来不是记住函数签名，而是判断哪个接口契约（Reader vs ReadSeeker vs ReadCloser）才匹配你的数据生命周期——比如 HTTP 响应体必须 Close，但 bytes.Buffer 就不用。