c.JSON()不能直接传入自定义json.Encoder，因其内部硬编码使用json.Marshal()，不暴露encoder实例或配置参数，无法启用SetEscapeHTML、控制浮点精度等；手动用json.NewEncoder需自行处理状态码、Content-Type及错误。
为什么 Gin 的 c.JSON() 不能直接传入自定义 json.Encoder
Gin 的 c.JSON() 内部硬编码使用 json.Marshal()，不暴露底层 json.Encoder 实例，也不接受 encoder 配置参数。这意味着你无法通过它启用 SetEscapeHTML(false)、控制浮点数精度、或注入自定义 MarshalJSON 之外的序列化逻辑（比如全局时间格式统一）。强行替换 json.Marshal 全局函数风险极高，且破坏并发安全。
用 json.NewEncoder() 替代 c.JSON() 手动写响应体
最可控的方式是绕过 c.JSON()，自己调用 json.NewEncoder() 写入 c.Writer，同时手动设置状态码和 Content-Type：
- 必须在写入前调用
c.Status(code)或c.Writer.WriteHeader(code)，否则默认 200 - 必须显式调用
c.Header("Content-Type", "application/json")，Gin 不会自动设 - 务必检查
encoder.Encode(obj)的 error，它可能因 io.Write 失败（如连接中断）而返回 - 若启用了 gzip 中间件，
c.Writer实际是gzipWriter，json.NewEncoder()可直接兼容
示例：
func handler(c *gin.Context) {
c.Status(200)
c.Header("Content-Type", "application/json")
encoder := json.NewEncoder(c.Writer)
encoder.SetEscapeHTML(false) // 关键：禁用 HTML 转义
if err := encoder.Encode(map[string]string{"msg": "hello <script>"});
err != nil {
// 连接已断开等场景下 err 不为 nil，此时不能再写响应
return
}
}
ShouldBindJSON 和自定义解码器不兼容
c.ShouldBindJSON() 固定使用 json.Unmarshal()，不支持传入 json.Decoder 或配置项。如果你需要：
- 忽略未知字段 → 用
jsoniter.ConfigCompatibleWithStandardLibrary替换默认 json 包（需提前全局替换） - 容忍空字符串转数字 → 必须自己用
json.NewDecoder()+UseNumber()解析，再手动赋值 - 字段名大小写不敏感 → Gin 原生不支持，得靠结构体 tag 或中间层预处理
没有“插拔式”绑定扩展点，所有定制都得在 ShouldBindJSON 之外另起炉灶。
真正需要全局定制时，优先改 json.Marshal 的输入，而非输出管道
比起动 encoder/decoder，更轻量、更安全的做法是规范数据源：
- 给 time.Time 字段加
json:"created_at" time_format:"2006-01-02T15:04:05Z"tag - 整型 ID 输出为字符串 → 用
ID int64 `json:"id,string"` - 避免
map[string]interface{}，改用明确结构体 + 自定义MarshalJSON方法 - 所有响应统一包装进
Response结构体，其MarshalJSON方法集中控制序列化逻辑
Encoder/Decoder 层的定制成本高、易出错，90% 的需求其实落在数据建模和 tag 控制上——这才是 Gin 场景下真正可维护的路径。
