Go语言无法延迟加载JSON文件，因json.Unmarshal需完整合法JSON；真正可行方案是用json.Decoder.Token()流式解析数组，配合json.RawMessage跳过大字段，且不可累积数据。
Go 语言没有“延迟加载 JSON 文件”的概念——json.Unmarshal 必须接收完整、合法的 JSON 值（单个对象或数组），无法切片、分页、跳读。所谓“延迟”，实际是放弃一次性解析，改用流式消费 + 按需解码。
为什么不能对 JSON 字符串做字节级分页
JSON 是嵌套语法结构，不是纯文本流。一个 { 可能跨多行、嵌套 10 层、中间夹着转义字符串 "a\"b" 或 base64 内容。按固定字节数截断必然破坏语法完整性：
-
json.Unmarshal([]byte(jsonStr[:n]), &v)几乎必 panic，报invalid character或unexpected end of JSON input - 用正则匹配
}位置“分页”：遇到{"msg": "a}b"}就失效 - 把文件当纯文本按行读再拼：仍得等完整结构才能调
Unmarshal，OOM 只是被推迟，没被解决
真正可行的流式延迟解析：用 json.Decoder + Token() 手动推进
这是标准库唯一能稳定控制内存的方案，适用于顶层为数组（如 [{},{},...]）的场景：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 先
dec.Token()消耗开头的[，确认是数组起始 - 进
for dec.More() { ... }循环，dec.More()自动识别逗号分隔和结尾] - 每次循环内只调一次
dec.Decode(&item)，内存中始终只有当前item实例 - 绝对不要写
dec.Decode(&[]T{})——它仍会分配整个底层数组，和Unmarshal一样 OOM
对大字段做真正延迟：用 json.RawMessage 占位
当某个字段体积巨大（如日志正文、base64 图片、嵌套长数组），但当前逻辑无需立刻解析时，用 json.RawMessage 跳过反序列化开销：
立即学习“go语言免费学习笔记（深入）”；
- 字段类型必须是
json.RawMessage（即[]byte别名），不能是string或*json.RawMessage - 声明时别加
omitemptytag，否则 JSON 中为null或缺失时该字段为nil，后续json.Unmarshal(raw, &v)会 panic - 使用前务必检查
len(raw) > 0；若需校验合法性但不解析，用json.Valid(raw)更轻量 -
json.RawMessage是原始字节快照，不持有独立内存拷贝——必须在父结构体还存活时完成二次解析，别存为全局变量或裸返回
最易被忽略的一点：流式解析的“低内存”只成立在你没在循环里累积数据。哪怕用了 Decoder，如果还往一个 []T 里不断 append，切片底层扩容机制会让内存占用线性增长，最终还是 OOM。
