c.JSON() 更安全，因自动设置 Content-Type、状态码并处理 json.Marshal() 错误；手动用 c.Data()+json.Marshal() 易漏 header、错 status 或 panic。
直接用 c.JSON()，别手写 json.Marshal() 再塞 c.Data() —— Gin 已封装好状态码、Content-Type 和错误处理，手动拼容易漏设 header 或错传 status。
为什么 c.JSON() 比 c.Data() + json.Marshal() 更安全
手动序列化再写响应体，常见问题包括：Content-Type 没设成 application/json; charset=utf-8、HTTP 状态码默认 200 但业务需要 400/500、json.Marshal() 出错时没 fallback 导致 panic 或空响应。
-
c.JSON(statusCode, obj)自动设置正确 header、调用json.Marshal()并处理 error（内部会 log panic 并返回 500） - 若
obj含非 JSON 可序列化字段（如func、chan、循环引用），c.JSON()会返回 500 并在日志中打印json: unsupported type - 不建议用
c.Set("Content-Type", "...")+c.String()：中文会乱码，且无法自动处理 struct tag（如json:"name,omitempty"）
c.JSON() 的 status 参数不是可选的，必须显式传
Gin 不提供无 status 的 c.JSON(obj) 重载，省略 status 会导致编译失败。常见误写是把 status 当作返回值处理，比如 return c.JSON(200, data) —— 实际上 c.JSON() 本身不 return 任何值，它直接写响应并标记已写入（c.Writer.Written() == true）。
- 正确写法：
c.JSON(200, map[string]interface{}{"msg": "ok", "data": result}) - 错误写法：
c.JSON(map[string]interface{}{...})（编译报错：missing argument） - 如果想统一处理 status，建议封装 helper 函数，例如
SuccessJSON(c *gin.Context, data interface{})，内部调用c.JSON(200, data)
中文乱码？检查 struct tag 和 Gin 版本
早期 Gin（"\u4f60\u597d"），影响可读性；新版默认关闭转义，但若结构体字段用了 json:",string" tag 或值本身是 string 类型却含非 ASCII 字符，仍可能出问题。
立即学习“go语言免费学习笔记（深入）”；
- 确保字段 tag 不滥用
string：例如Age int `json:"age,string"`会让数字变字符串，但和中文无关；乱码主因是响应 header 缺失 charset 或前端没按 UTF-8 解码 - Gin v1.9+ 默认不转义中文，若仍见 \uXXXX，检查是否手动调了
json.Encoder.SetEscapeHTML(true)（Gin 内部不用管） - 最简验证：用
c.JSON(200, gin.H{"text": "你好"})，curl -i 看响应头是否有Content-Type: application/json; charset=utf-8
真正容易被忽略的是：当 handler 中多次调用 c.JSON()（比如 defer 里又写一次），Gin 会 panic 报 write on flushed body —— 因为 HTTP 响应只能写一次。这类错误不会出现在开发机 console，而是在 prod 日志里静默失败。务必确保每个请求路径只触发一次响应写入。
