strings.Reader不适合流式解析长字符串，它仅将字符串转为io.Reader接口，无分块、缓冲或解码能力；配合bufio.Scanner可实现行级解析，需注意默认单行上限64KB，超长行需调用scanner.Buffer调整缓冲区。
strings.Reader 是不是适合流式解析长字符串？
不是。它只是把字符串转成 io.Reader 接口，不提供“流式解析”能力——它不会自动分块、不会缓冲控制、也不会按需解码。你拿到的只是一个可重复读、支持 Seek 的只读视图，底层仍是整块字符串内存拷贝（实际是共享底层数组，但语义上仍是全量加载）。真正需要流式处理时，strings.Reader 本身不解决内存或解析逻辑问题，只是个起点。
怎么用 strings.Reader 配合 bufio.Scanner 做行级解析？
这是最常见也最实用的组合：用 strings.Reader 提供数据源，bufio.Scanner 负责按行切分并控制内存使用。注意默认 Scanner 单行上限是 64KB，超长行会报 bufio.Scanner: token too long 错误。
- 调用
scanner.Split(bufio.ScanLines)显式指定分隔策略（虽是默认值，但显式写更稳妥） - 如需处理超长行，提前用
scanner.Buffer(make([]byte, 4096), 1 扩大缓冲区（第二个参数是最大令牌长度） -
strings.Reader本身不管理生命周期，无需 Close；但 Scanner 的Scan()返回 false 后，Err()可检查是否因 I/O 错误终止
reader := strings.NewReader(largeString)
scanner := bufio.NewScanner(reader)
scanner.Buffer(make([]byte, 4096), 1<<20) // 支持最长 1MB 行
for scanner.Scan() {
line := scanner.Text() // 注意：Text() 返回的是底层 buffer 的切片，不要长期持有
process(line)
}
if err := scanner.Err(); err != nil {
log.Fatal(err) // 比如遇到 bufio.Scanner: token too long 就在这里暴露
}
为什么不能直接用 strings.Reader + json.Decoder 解析 JSON 流？
因为 json.Decoder 确实接受 io.Reader，但它要求输入是合法、连续的 JSON 文本（如一个数组或多个对象拼接），且不支持跳过空白或部分解析。如果 largeString 是纯 JSON 数组（[{...},{...}]），可以；但如果是带前缀/后缀的混合文本（如 HTML 中嵌入 JSON），或内容含未转义换行、BOM、注释等，json.Decoder 会直接失败，错误信息通常是 invalid character ... 或 unexpected end of JSON input。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
strings.Reader不做任何预处理，BOM 字节（如\ufeff）会原样传给json.Decoder，导致解析失败 - 若字符串开头有空格、换行、HTML 标签等非 JSON 内容，必须先用
bytes.Trim或正则提取 JSON 片段，再喂给json.NewDecoder - 多对象拼接（NDJSON）需手动循环调用
Decode()，每次只解一个值；而单个 JSON 数组则只能一次性解出整个 slice，失去“流式”意义
什么时候该放弃 strings.Reader，改用 io.MultiReader 或 bytes.NewReader？
当你的“长字符串”实际来自多个片段、或需要插入前导/后置内容（比如加 header、补 footer）、或原始数据是 []byte 时，strings.Reader 反而多一层转换开销。它本质是为 string 类型设计的封装，底层仍调用 copy 和 utf8 相关逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 如果原始数据已经是
[]byte，直接用bytes.NewReader(data)，避免 string ↔ []byte 转换（尤其对含非 ASCII 字符的字符串，string转换可能触发内存分配） - 若需拼接多个 reader（如 header + body + footer），用
io.MultiReader(headerR, bodyR, footerR)，比先拼字符串再建strings.Reader更省内存 - 对超大文本（GB 级），
strings.Reader仍会完整加载进内存 —— 此时应考虑 mmap 或分块读文件，而非在内存里构造 string
真正容易被忽略的点是：strings.Reader 的 Len() 和 Size() 返回的是原始字符串长度（rune 数），但 io.Reader 接口不保证按 rune 边界读取；所有基于 Read() 的操作都以 byte 为单位，UTF-8 多字节字符可能被截断 —— 如果你在自定义解析器里依赖 Read() 返回的字节数做偏移计算，得自己处理 UTF-8 边界。
