strings.NewReader几乎零开销，因不拷贝字符串、不验证UTF-8、不分配内存，仅封装底层指针、长度及读位置i；Read本质为copy(b, s[i:])并更新i，无堆分配。
strings.NewReader 为什么几乎零开销
它不拷贝字符串内容，也不做 UTF-8 验证或内存分配，只是把 string 的底层指针和长度打包进一个 Reader struct，i 字段记录当前读取位置（int64）。每次 Read 调用本质是 copy(b, s[i:])，然后更新 i += n —— 全部基于切片语法，无额外堆分配。
这意味着：
- 传入的字符串必须在 reader 生命周期内保持有效（Go 中 string 本身不可变，这点安全）
- 哪怕字符串是 100MB，
strings.NewReader构造本身只占几十字节内存 - GC 会一直持有整个原始字符串，直到该
Reader被回收 —— 如果你只读前几个字节就丢弃 reader，大字符串仍无法被释放
Read、ReadAt、Seek 的行为差异必须分清
Read 是带状态的：它依赖并推进内部读取位置 i；ReadAt 是无状态的：它忽略 i，直接从指定 off 偏移读，且不修改 i；Seek 则显式重置 i，但只支持 io.SeekStart 和 io.SeekCurrent，不支持 io.SeekEnd。
常见误用：
立即学习“go语言免费学习笔记（深入）”；
- 调用
ReadAt后以为i变了，接着调Read却从头开始读 —— 实际上i没动过 - 用
Seek(0, io.SeekEnd)想跳到末尾，结果 panic：strings: invalid offset - 对已读完的 reader 调
Seek(0, io.SeekStart)期望重放，但没效果 —— 因为Seek成功返回新位置，但后续Read仍可能立即返回io.EOF（如果之前已读完）；正确做法是重新调strings.NewReader(s)
Len() 和 Size() 不是一个东西
Size() 永远返回 int64(len(s))，即原始字符串总长度；Len() 返回剩余可读字节数，等于 int(Size() - i)。两者差值就是已读字节数。
这个区别直接影响逻辑判断：
- 用
Len() == 0判断是否读完，比检查err == io.EOF更可靠（尤其在多次Read后） - 想“跳过前 N 字节”，别写
r.Seek(int64(N), io.SeekStart)然后立刻Read，要先确认N ，否则 <code>Seek失败 -
ReadRune会影响prevRune字段，但不影响Len()计算逻辑 —— 它仍是按字节算剩余长度
别试图复用单个 strings.Reader 实例做多轮读取
strings.Reader 不是 bytes.Buffer，它没有 Reset 方法（注意：标准库中 strings.Reader **没有** Reset 方法，某些文章提到的是自定义扩展或混淆了 bytes.Reader），也没有 Close。一旦读完或 Seek 越界，它就进退两难。
真正安全的复用方式只有两种：
- 每次需要读取时，调用
strings.NewReader(s)新建实例 —— 开销极小，推荐用于测试、配置解析等短生命周期场景 - 若需反复读同一字符串且性能敏感（比如高频 HTTP mock），改用
bytes.NewReader([]byte(s))，它支持Seek(0, 0)重置，且底层是可重用的切片
硬要给 strings.Reader 加“重置”逻辑，比如反射改 i 字段，属于破坏封装，Go 1.22+ 可能因编译器优化失效，不建议。
