strings.reader本身不提供流式解析能力，仅将字符串转为io.reader接口，底层仍全量持有；配合bufio.scanner时需调用scanner.buffer()设置缓冲区容量与最大token长度，否则超64kb单行会触发“token too long”错误。
strings.Reader 本身不提供“流式解析”能力，它只是把字符串转成 io.Reader 接口，底层仍是一次性加载整块字符串（共享底层数组，但语义上仍是全量持有）。真要高效读取长字符串，关键不在 strings.Reader 自身，而在它和谁配合、怎么用。
strings.Reader.Read() 为什么不能直接用于大字符串分块读取？
它确实能分块读，但容易误判“已读完”或触发意外 io.EOF：
- Read(b []byte) 每次最多读 len(b) 字节，但返回的 n 可能小于 len(b)（比如只剩 2 字节，而 b 长 4）
- 如果没检查 err == io.EOF 就跳出循环，可能漏掉最后不满缓冲区的片段
- 它不维护状态机，也不感知行、JSON 对象、XML 标签等语义边界，纯字节搬运
- 多次调用 Read() 不会自动跳过 BOM（如 \ufeff），后续解析器可能直接失败
配合 bufio.Scanner 做行级流式处理时要注意什么？
这是最常用也最易踩坑的组合：
- 默认单行上限是 64KB，超长行会报 bufio.Scanner: token too long
- 必须提前调用 scanner.Buffer(make([]byte, 4096), 1 设置最大令牌长度（第二个参数才是关键）<br>
- <code>scanner.Text() 返回的是底层 buffer 的切片，如果保存引用或跨 goroutine 使用，可能被下一次 Scan() 覆盖
- scanner.Split(bufio.ScanLines) 显式指定策略更稳妥，避免因 scanner 内部默认行为变更导致隐性问题
- strings.Reader 不需要 Close()，但 scanner.Err() 必须检查，否则 I/O 错误会被静默吞掉
为什么不能拿 strings.Reader 直接喂给 json.Decoder？
因为 json.Decoder 要求输入是合法、连续、无干扰的 JSON 流：
- 若字符串含 HTML 前缀（如 "<script>var data = "</script> + JSON）、BOM、注释或未转义换行，会立刻报 invalid character 或 unexpected end of JSON input
- strings.Reader 不做任何预清洗，BOM 字节原样透传过去
- 即使内容是纯 JSON 数组（[{...},{...}]），也要确保没有尾随空白或换行干扰解码器状态
- 真正安全的做法是先用 bytes.Trim 或正则剥离非 JSON 前缀，再确认首字符是 [ 或 {，最后才交给 json.NewDecoder
什么时候该放弃 strings.Reader，换别的方案？
当字符串实际来自文件、网络或生成器时：
- 如果原始数据本就来自磁盘（*os.File）或 HTTP body（http.Response.Body），直接用它们作为 io.Reader，别先读进内存再包一层 strings.Reader
- 如果字符串是拼接生成的（比如模板渲染结果），考虑用 strings.Builder + strings.NewReader 组合，但注意 Builder.String() 会触发一次内存拷贝
- 若需按 rune（而非 byte）边界切分，ReadRune() 效率远低于批量 Read()，应避免在热路径中单个读取中文等多字节字符
- 超过 10MB 的字符串，strings.Reader 已经不是瓶颈，真正卡点通常是后续解析逻辑或内存带宽，此时该查 profile，而不是换 Reader
真正麻烦的从来不是怎么读，而是读完之后——要不要复制、在哪切分、如何容错、是否复用 buffer。这些细节不写进代码里，光靠 strings.Reader 名字里的 “Reader” 两个字，解决不了任何实际问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
