Gin 默认使用 encoding/json，性能弱且兼容性差；替换为 jsoniter 可提速 2–3 倍并解决字符串数字、PHP 空数组、时间格式等反序列化问题，但必须通过编译 tag（-tags=jsoniter）启用，否则 ShouldBindJSON 仍走标准库。
直接结论：Gin 默认用 encoding/json，性能弱、兼容性差；换成 jsoniter 能显著提升解析速度（实测快 2–3 倍），并解决字符串数字、空数组、时间格式等常见反序列化问题——但必须显式启用编译 tag，否则无效。
为什么 ShouldBindJSON 还是走标准库？
很多人改了 import、写了 jsoniter.ConfigCompatibleWithStandardLibrary，但 c.ShouldBindJSON() 依然报错或不兼容，根本原因是 Gin 的 JSON 绑定逻辑由内部 binding.JSON 实现决定，而它是否使用 jsoniter 取决于构建时的 go build -tags=jsoniter，不是运行时 import 控制的。
- 源码里明确用了
// +build jsoniter条件编译，没加 tag 就永远走encoding/json - 即使你手动
jsoniter.Unmarshal()成功，c.ShouldBindJSON()仍不受影响 - 验证方式：启动后打印
json.Marshal的函数地址，和jsoniter.Marshal对比是否一致
如何正确启用 jsoniter 并验证生效？
不是改代码，而是改构建命令。Gin 内部已预埋支持，只需让编译器“看到”那个 tag。
- 编译时加
-tags=jsoniter：例如go build -tags=jsoniter -o server main.go - 运行时也支持：
go run -tags=jsoniter main.go - CI/CD 中别漏掉：Dockerfile 的
go build行必须带该 tag - 验证是否生效：在 handler 里执行
fmt.Printf("%p", json.Marshal)，如果地址和jsoniter.Marshal一致，说明切换成功
jsoniter 解析时容易踩的坑
它虽兼容标准库 API，但行为细节有差异，尤其在边界 case 上：
- 字符串数字自动转 int/float：默认开启，但若结构体字段是
int而 JSON 传"123"，会成功；标准库直接报错——这既是优点也是隐患，需确认业务是否允许这种宽松 - PHP 风格空数组
[]→nil：对 slice 字段，jsoniter默认把空数组解成nil，而标准库是[]；可通过jsoniter.Config{StrictNull: true}关闭 - 时间格式支持更广：能解析
"2024-01-01"、"2024-01-01T00:00:00Z"等多种格式，但需确保结构体字段是time.Time且 tag 为json:"xxx,time_rfc3339" - 不支持
json:",string"这种强制字符串解析 tag：这是encoding/json的非标准扩展，jsoniter不认，得改用自定义UnmarshalJSON方法
要不要替换 c.JSON() 为直接 jsoniter.Marshal()？
可以提效，但只在高频、简单响应场景值得做——多数接口没必要。
-
c.JSON(200, data)内部会反射判断类型、调用json.Marshal，再写 response；而bytes, _ := jsoniter.Marshal(data); c.Data(200, "application/json", bytes)省掉反射和封装 - 实测单次节省约 0.05ms，QPS 提升 5–8%，但代价是失去
c.JSON的错误处理和 Content-Type 自动设置 - 真正关键的是避免在循环里反复调用
c.JSON，比如分页返回多个 item 时，应先拼好整个 map 或 slice 再一次性序列化
最常被忽略的一点：jsoniter 的加速效果在小 payload（
