io包核心在于理解关键接口、组合逻辑与错误传播路径；从io.reader/io.writer注释入手，掌握io.eof等错误语义，厘清io.copy三路分支、readfull/readatleast差异及limitedreader/sectionreader边界处理。
io 包不是靠“读完全部源码”来掌握的，而是靠定位关键接口、理解组合逻辑、看清错误传播路径。它小而精，但设计密度高——直接看 io.go 文件（约 500 行）就能覆盖核心。
从 io.Reader 和 io.Writer 接口开始，别跳过注释
打开 $GOROOT/src/io/io.go，第一眼就是这两个接口定义。重点不是函数签名本身，而是紧随其后的英文注释：
-
Read(p []byte)的注释明确说：“即使返回n ，也可能已用尽整个 <code>p作暂存”，这意味着你不能假设未读满就代表 EOF 或错误 -
Write(p []byte)注释强调：“调用方必须检查n 并重试剩余部分”，这是 <code>io.ErrShortWrite存在的根本原因 - 所有错误变量（
io.EOF、io.ErrUnexpectedEOF、io.ErrShortWrite）都在同一文件顶部定义，它们的文档说明了语义边界——比如io.EOF只用于“优雅结束”，而意外截断应返回io.ErrUnexpectedEOF
盯住 io.Copy 的三路分支逻辑
io.Copy 是实际使用率最高的函数，它的源码（copy.go）暴露了 Go I/O 的底层调度哲学：
- 第一优先：如果
src实现了WriterTo接口（如*os.File），直接调用src.WriteTo(dst)—— 零拷贝，绕过缓冲区 - 第二优先：如果
dst实现了ReaderFrom接口（如*os.File），调用dst.ReadFrom(src)—— 同样避免中间分配 - fallback：两者都不满足时，才用默认的
32KB缓冲区循环Read→Write，且每次Write后都检查是否n ，遇到就返回 <code>io.ErrShortWrite
这个结构解释了为什么对文件到文件的复制，io.Copy 性能极好；但对需要修改内容的场景（如加 header），它无法介入数据流，必须手动控制。
注意 io.ReadFull 和 io.ReadAtLeast 的错误语义差异
这两个函数常被误用，区别不在功能而在错误返回逻辑：
-
io.ReadFull(r, buf)：要求**必须读满**len(buf)字节，否则返回io.ErrUnexpectedEOF（哪怕只差 1 字节）或其它错误。适合解析固定长度头、二进制协议 -
io.ReadAtLeast(r, buf, min)：只要求至少读min字节，返回值n是实际读取数，n >= min才算成功；若提前 EOF 且n ，才返回 <code>io.ErrUnexpectedEOF - 两者都不把
io.EOF当作错误返回——只有未达预期时才触发io.ErrUnexpectedEOF，这点和io.Read原语行为一致
别忽略 io.LimitedReader 和 io.SectionReader 的边界处理
这两个封装类型看似简单，但它们的 Read 方法重写了 EOF 判定逻辑：
-
io.LimitedReader.R在N 时直接返回 <code>(0, io.EOF)，不调用底层Read；但若底层返回io.EOF且N > 0，它会把io.EOF转为nil错误并截断返回（模拟“还有数据但被限流”） -
io.SectionReader的Read在越过off + n边界时，会主动限制copy长度，并在读完指定区间后返回(0, io.EOF)，而不是依赖底层 Reader 的 EOF - 这意味着：用
io.LimitedReader包裹一个网络连接，即使连接还活着，读到限额也会返回io.EOF——这可能被上层误判为流结束
真正难啃的不是代码行数，而是这些细粒度的错误转换和边界重定义。读源码时，盯着每个 if err == io.EOF { ... } 分支，看它被谁改写、被谁透传、被谁压制，就摸清了整个包的呼吸节奏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
