直接替换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 网关每秒数千次请求体解析、日志行批量反序列化。它靠预编译解析逻辑、零拷贝字符串读取、绕过反射来提速——这些开销只在重复调用中摊薄。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 一次性加载 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，只按路径逐层跳过无关内容。
- 写法示例：
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 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。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
