json.Unmarshal会卡死是因为它将整块文件加载进内存并递归建树，100MB日志可能占用300MB+堆内存，且强制展开所有字段（如trace.stack），导致GC尖峰和吞吐下降；正确做法是用json.Decoder流式解析、bufio.Scanner按行切分、sync.Pool复用缓冲区，实现边读边判、字段级按需提取与KB级内存控制。
实时文件分析引擎不是“读得快”，而是“边读边判、不等结尾、错峰处理”——用 json.Decoder 流式解析 + bufio.Scanner 按行切分 + sync.Pool 复用缓冲区，才能稳住毫秒级延迟和 KB 级内存占用。
为什么 json.Unmarshal 一用就卡死
它把整块文件加载进内存再递归建树，100MB 日志可能吃掉 300MB+ 堆内存，GC 尖峰直接拖慢吞吐。更致命的是：你只关心 "status" 字段，它却把 "trace.stack" 全展开、分配、拷贝。
- 错误现象：
json.Unmarshal(data, &v)后再取v.Status—— 本质仍是全量解析，没跳过任何字段 - 适用场景：配置文件、小体积 RPC 响应体（
- 真实需求：日志流、IoT 上报、NDJSON 文件，结构固定但量大
用 json.Decoder + bufio.Scanner 处理 NDJSON
每行一个 JSON 对象（如 Nginx 日志、Kafka 原始消息），不能把整个文件丢给 json.Decoder，否则第一个对象解析完就 EOF。
- 必须按行读取：
scanner := bufio.NewScanner(file)，每行构造strings.NewReader(line)传给新json.Decoder - 禁止复用同一个
json.Decoder实例——它内部有缓冲和状态，跨行会错乱 - 加长度限制：
if len(line) > 1024*1024 { continue }，防止单行畸形 JSON 耗尽内存 - 解析失败时打印该行前 100 字符 + 行号，方便定位脏数据
字段级按需提取：跳过无关结构，只取目标值
别解到 struct 或 map，用 decoder.Token() 手动推进，命中 key 后立刻读值。比如只提 "event_type" 和 "payload.size"，其他全跳过。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 用
json.Delim判断{/}边界，进入"payload"后，下一层 key 是"size"才提取，否则退出该对象 - 避免
decoder.Decode(&emptyStruct)—— 这等于白跳，仍全量解析 - 务必检查
token.Error()，某些脏数据会在null后紧跟非法字符，触发InvalidCharacterError
缓冲区与 sync.Pool：控制内存抖动
高频写入或解析时，频繁 make([]byte, N) 会触发 GC 尖峰。用 sync.Pool 复用缓冲区，配合预估大小，让内存稳定在 KB 级。
- 为
bufio.Scanner设置缓冲：scanner.Buffer(make([]byte, 0, 64*1024), 1024*1024)，避免默认 64KB 不够导致扩容 - 为 JSON token 解析复用 byte slice：
bufPool := sync.Pool{New: func() interface{} { return make([]byte, 0, 4096) }} - 每次解析前
buf := bufPool.Get().([]byte)，用完bufPool.Put(buf[:0]) - 别用
bufio.Writer包裹文件句柄——它的缓冲会绕过file.Sync()，WAL 场景下数据可能丢失
最易被忽略的点：NDJSON 的行边界不是 \n，而是 \r\n 或 \r；真实日志里常混用，bufio.Scanner 默认只认 \n，需用 Split 自定义分隔符，否则某行末尾的 \r 会被吞掉，导致后续 JSON 解析错位。
