自定义 io.reader 必须严格处理 n 和 err，因为下游标准库组件（如 io.copy、json.decoder）依赖其返回值做流控；n == 0 && err == nil 会直接 panic，n > 0 && err == io.eof 表示正常结束，n == 0 && err == io.eof 表示空流，其他 err 需显式处理。
为什么自定义 io.Reader 必须严格处理 n 和 err
因为下游所有标准库组件（io.Copy、json.Decoder、pg.CopyFrom）都依赖 Read 的返回值做流控。写错会直接 panic 或丢数据。
-
n == 0 && err == nil是非法状态，Go 运行时会立即 panic —— 不是警告，是崩溃 -
n > 0 && err == io.EOF表示“这次读到了，之后没数据了”，这是正常结束信号 -
n == 0 && err == io.EOF表示空流（比如空文件），也合法，但不能和上一条混淆 - 只要
err != nil && err != io.EOF，就是真实错误，调用方通常会中止流程，别吞掉
如何实现一个带行过滤的 Reader（比如跳过注释和空行）
关键不是“怎么读”，而是“怎么缓存+推进”。你得维护一个内部缓冲（比如 bufio.Scanner 或手动切分），每次 Read 调用只吐出当前行的有效字节，不含 \n 或注释前缀。
- 别在
Read里反复调用底层Read直到读满一行 —— 这会导致阻塞或重复读 - 推荐用
bufio.NewReader封装原始源，再在自定义Read中调用ReadString('\n')或ReadLine()拿整行，判断后写入p - 注意：如果某次
Read(p)请求的长度小于一行字节数，你要拆开返回，不能等——流式本质就是不保证块大小 - 示例核心逻辑：
line, err := r.scanner.ReadString('\n')→ 过滤 →n = copy(p, filteredLine)→ 返回n, err
为什么不用 strings.NewReader 做流式测试
它内部是内存全量加载 + 指针偏移，完全不模拟真实 IO 的分块、延迟、部分读行为，测不出流式逻辑缺陷。
- 真要测流式解析（比如逐行导入大日志），得自己造一个「按需吐字节」的 Reader
- 用
sync.Mutex+[]byte+ 当前 offset 管理剩余数据，每次Read只取min(len(p), len(remaining)) - 测试时可在
Read里加time.Sleep模拟网络延迟（仅限测试） - 别在
Read里做正则匹配或解密 —— 这会让调用方误判为 IO 卡顿，实际是 CPU 阻塞
封装 base64 字符串为 io.Reader 的坑
常见错误是手动截断字符串或忽略填充符，导致 base64.NewDecoder 报 illegal base64 data。
- 正确做法：用
strings.NewReader("SGVsbG8=")→base64.NewDecoder(base64.StdEncoding, ...) - base64 解码器本身是
io.Reader，但它要求输入是合法 base64 字节流；原始字符串必须完整，不能去掉末尾的= - 如果 base64 数据来自配置项，确保它没被 YAML/JSON 解析器自动 trim 或转义
- 别手写 base64 解码循环 ——
base64.NewDecoder已处理边界、填充、流式解码，自己实现极易出错
p。最容易被忽略的是 n == 0 && err == nil 的非法性 —— 它不是“还没读到”，而是协议级错误。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
