io.reader 和 io.writer 必须实现 read([]byte)/write([]byte) 因为 go 流接口采用缓冲驱动模型，要求每次按需填满或消费字节切片，以保障零拷贝组合、中间件包装和内存安全；必须严格检查返回的 n 和 err，不可假设 len(p) 全部读写。
为什么 io.Reader 和 io.Writer 必须实现 Read([]byte) / Write([]byte) 而不是 Read(io.Reader)
因为 Go 的流接口设计是「缓冲驱动」而非「流嵌套驱动」——底层不关心数据来源或去向，只约定「每次按需填满/消费一个字节切片」。这保证了零拷贝组合（比如 io.MultiReader）、中间件式包装（比如加解密、压缩）和内存安全的统一模型。
常见错误是试图在 Read 方法里直接调用另一个 io.Reader 的 Read 却忽略返回的 n, err：如果对方只读了 3 字节但你期望 1024，你的缓冲区后 1021 字节就是脏数据。
- 必须严格检查
n，不能假设len(p)全部写入/读出 - 遇到
io.EOF时，只要n > 0就得先返回已读/已写字节数，再返回err - 不要在
Read里做阻塞等待（除非你明确控制底层资源），否则会卡住整个调用链
封装带状态的 Reader：比如从 base64 字符串边解码边读取
典型场景是配置文件里存了一段 base64 编码的二进制内容，你想把它当普通 io.Reader 传给 json.NewDecoder 或 png.Decode。这时候不能一次性解码到内存，得流式处理。
关键点在于：base64 解码器本身是 io.Reader，但它的输入必须是 []byte；你需要一个中间结构把字符串转成 bytes.Reader，再链上 base64.NewDecoder。
立即学习“go语言免费学习笔记（深入）”；
- 别手写循环解码逻辑——用
base64.NewDecoder包装原始io.Reader最稳妥 - 如果原始数据是
string，先用strings.NewReader(s)转成io.Reader，再喂给 base64 解码器 - 注意 base64 编码末尾可能有
=填充，base64.NewDecoder会自动处理，但如果你自己截断字符串就可能触发illegal base64 data
示例：
reader := base64.NewDecoder(base64.StdEncoding, strings.NewReader("SGVsbG8=")) 这样得到的 reader 就是合法的 io.Reader，可直接传给任何接受该接口的函数。
Writer 封装陷阱：日志前缀、大小限制、panic 恢复
自定义 io.Writer 最容易翻车的地方是误吞错误、忽略写入长度，或者在 Write 里 panic 导致上游调用崩溃（比如 fmt.Fprintf 内部调用你的 Write）。
- 所有下游
Write调用必须检查返回的n, err，不能只看err—— 比如磁盘满时可能写入部分字节后才报错 - 加前缀的 Writer（如每行加
[INFO]）不能简单拼接字符串再写：要区分「行边界」，最好用bufio.Scanner或手动找\n，否则二进制数据里的\n会被误切 - 带大小限制的 Writer（如只允许写 1MB）应在
Write中累加计数，并在超限时返回<nil></nil>（不是io.ErrShortWrite！）+ 实际写入字节数，否则像io.Copy会反复重试
测试自定义 Reader/Writer 时绕不开的三个 case
光跑通「能读能写」远远不够。Go 标准库里大量函数（io.Copy、io.ReadAll、json.Decoder）对边缘行为极其敏感。
- 传入长度为 0 的
[]byte：你的Read/Write必须返回n == 0, err == nil，否则io.Copy会提前退出 - 底层返回
n == 0, err == io.EOF：这是合法终态，你的封装不能把它转成err != nil并丢弃n - 并发调用：如果内部有共享状态（比如计数器、buffer），必须加锁；但别锁整个
Read——只锁真正共享的部分，否则性能归零
最省事的验证方式是用 io.Copy(ioutil.Discard, yourReader) 和 io.Copy(yourWriter, bytes.NewReader(data))，观察是否 panic、死锁或漏数据。这些比写单元测试更快暴露问题。
流接口看着简单，但每个 Read / Write 调用都在和调度器、缓冲区、错误传播规则打交道。少一个 n 判断，多一次无条件 return err，就可能让下游逻辑静默失败。
