json.newdecoder专为流式解析设计，适用于读取大文件、http响应体、网络连接流或不确定长度的json数据，边读边解析，内存占用稳定在kb级别。
json.NewDecoder 适合读什么场景
它专为流式、增量解析设计，比如读取大文件、HTTP响应体、网络连接流，或者不确定长度的 JSON 数据。和 json.Unmarshal 不同，json.NewDecoder 不要求一次性把整个数据加载进内存，而是边读边解析，内存占用稳定。
常见误用：拿它去解析小段固定字符串（比如 "{\"name\":\"Alice\"}"），这时直接用 json.Unmarshal 更简单、更高效。
- ✅ 正确场景：读
os.Stdin、http.Response.Body、os.Open("huge.json") - ❌ 错误场景：传入
strings.NewReader("{\"x\":1}")做单元测试（除非刻意模拟流） - ⚠️ 注意：它不支持“跳过字段”或“部分解析”，每次调用
Decode都期望一个完整 JSON 值（对象、数组、字符串、数字等）
Decode 多次调用时的常见错误
如果源数据是多个 JSON 值连在一起（比如换行分隔的 JSON Lines 格式），必须手动控制读取节奏；否则 Decode 会卡在第一个值后，后续调用直接报 EOF 或 invalid character。
典型错误现象：json: cannot unmarshal object into Go value of type string —— 实际是因为前一次 Decode 已读完一个对象，下一次却传入了结构体指针，但底层 reader 已到末尾或位置错乱。
- ✅ 正确做法：对 JSON Lines，每次用
decoder.Decode(&v)解一个，循环处理 - ✅ 对混合类型（如先对象后数组），需确保目标变量类型匹配，或用
interface{}+ 类型断言 - ❌ 不要反复用同一个
decoder解不同结构体而不清空/重置 reader ——json.Decoder本身无重置方法，reader 位置不可回退
性能与缓冲区的关键细节
json.NewDecoder 底层依赖传入的 io.Reader，它的性能直接受 reader 缓冲能力影响。未缓冲的 os.File 或 net.Conn 可能触发大量小 read 系统调用，拖慢解析速度。
不是加个 bufio.NewReader 就万事大吉 —— 缓冲区太小（如默认 4KB）在解析深层嵌套或长字符串时仍可能频繁 flush；太大又浪费内存。
- ✅ 推荐：对文件用
bufio.NewReaderSize(f, 64*1024)（64KB 缓冲） - ✅ 对 HTTP Body，通常无需额外包装（
http.Response.Body本身已带缓冲） - ⚠️ 注意：
Decoder内部会预读少量字节判断类型，若 reader 在中间断开（如网络超时），可能丢失已预读但未消费的数据
error 处理不能只看 Decode 返回值
Decode 返回 error 仅反映本次解析失败，但 reader 可能已处于损坏状态（比如因语法错误提前退出）。更隐蔽的问题来自底层 reader 自身的 error，例如网络连接中断、磁盘 I/O 错误，这些可能在后续 Decode 调用中才暴露为 unexpected EOF 或 read: connection reset by peer。
- ✅ 必须检查每次
Decode的 error，且区分io.EOF（正常结束）和其他 error - ✅ 若用在 HTTP 客户端，记得 defer
resp.Body.Close()，否则连接不会复用，decoder 可能卡住 - ⚠️ 容易忽略：
Decoder不提供“跳过非法 JSON”的能力，遇到格式错误只能终止，无法自动同步到下一个合法值（不像某些日志解析器）
bufio.Reader 或早关一次 body，就足以让 Decode 行为完全偏离预期。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
