直接替换import不能提速，必须显式配置兼容性：全局变量用jsoniter.ConfigCompatibleWithStandardLibrary.Froze()、按需启用SetSortMapKeys(true)和MarshalNilSliceAsEmpty:true，并仅在高频稳定结构体场景下使用。
直接替换 import 就能提速？别急，先看这三处必改点
不能只改 import "encoding/json" 为 import jsoniter "github.com/json-iterator/go" 就完事。最常踩的坑是：程序跑起来但行为异常，比如 map 序列化顺序乱、nil slice 输出 null 而非 []、json.RawMessage 解析失败。必须显式配置兼容性。
- 全局变量要初始化为
jsoniter.ConfigCompatibleWithStandardLibrary.Froze()，而不是直接用jsoniter.ConfigDefault - 若依赖 map 字段序列化顺序（如签名计算），需额外调用
.SetSortMapKeys(true) - 处理空 slice 时，默认输出
null；要保持标准库行为，得用jsoniter.Config{MarshalNilSliceAsEmpty: true}
高频解析场景才值得换：别在配置加载里硬上 jsoniter
jsoniter 的优势集中在「结构体稳定 + 字段固定 + 解析频次高」的路径，比如 API 网关每秒数千次请求体解析、日志行批量反序列化。它靠预编译解析逻辑、零拷贝字符串读取、绕过反射来提速——这些开销只在重复调用中摊薄。
- 一次性加载 YAML/JSON 配置文件？标准库更稳，jsoniter 没收益还可能因类型推导差异引发隐晦 bug
- 结构体字段经常增删或大量用
map[string]interface{}？jsoniter 的类型断言开销反而比标准库反射更大 - Go 1.21+ 用户注意：标准库已优化 struct tag 解析和缓冲机制，真实业务 payload 下差距缩至 10%~25%，先跑
go test -bench=.再决定
只取 1~2 个字段？用 jsoniter.Get 跳过完整反序列化
当你只需要 JSON 中少数顶层或嵌套字段（比如 webhook body 里的 "event_type" 和 "data.id"），jsoniter.Get 比 Unmarshal 快得多，且内存占用极低——它不构造 struct，只按路径逐层跳过无关内容。
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 写法示例：
val := jsoniter.Get(data, "user", "profile", "age").ToInt()，支持数组索引如"items", "0", "name" - 路径不存在时，
.ToString()返回空字符串、.ToInt()返回 0 —— 不 panic，但容易掩盖字段缺失逻辑，建议配合.Exists()判断 - 别用它反复提取十几个字段：此时定义 struct +
Unmarshal更清晰，且 jsoniter 的 struct 解析本身已足够快
想再快 30%？生成 fastpath，但只对高频结构体做
jsoniter 的 fastpath 是编译期生成专用 marshal/unmarshal 函数，彻底绕过反射和运行时类型匹配。但它会增加构建时间、二进制体积，并要求你手动触发代码生成——不是所有结构体都值得。
立即学习“go语言免费学习笔记（深入）”；
- 安装工具：
go install github.com/json-iterator/go/cmd/jsoniter@latest - 在目标 struct 上方加注释：
//go:generate jsoniter -i . -o ./json_gen.go - 只对 API 请求/响应体这类高频、稳定、字段明确的结构体启用；内部临时 DTO 或测试数据没必要
- 生成后记得
go generate并提交json_gen.go，否则 CI 构建会失败
json.RawMessage 的默认行为差异：它不保证后续能用标准库 json.Unmarshal 再解析该字段。如果业务里存在“先用 RawMessage 接收，再按类型分支解析”的模式，必须统一用 jsoniter 的 Unmarshal，否则 runtime panic。 
