c.JSON() 更可靠，因它自动设 Content-Type 和状态码，并在 JSON 序列化失败时记录日志并返回 500，而手动组合易漏 header、错状态码或 panic。
直接用 json.NewEncoder(w).Encode(v) 或 c.JSON(status, v)，别手写 json.Marshal 再塞 w.Write 或 c.Data——前者易漏 header、错状态码，后者可能 panic 且绕过 Gin 的错误处理。
为什么 c.JSON() 比手写 json.Marshal() + c.Data() 更可靠
c.JSON() 是 Gin 封装好的安全入口：它自动设置 Content-Type: application/json; charset=utf-8、显式写入你传入的 status 码、并在 json.Marshal() 失败时记录日志并返回 500，而不是让 handler panic 或返回空响应。
- 手动组合常见问题：
Content-Type没设 → 浏览器当 text/plain 解析；status 忘传 → 默认 200，掩盖业务错误；json.Marshal()返回 error 却没检查 → 前端收空体或截断 JSON -
c.JSON(200, data)必须带 status 参数，c.JSON(data)编译报错 - 如果
data含func、chan、未导出字段（小写开头）、或循环引用，c.JSON()会返回 500 并在日志里打出json: unsupported type - 中文乱码？先确认
c.JSON(200, gin.H{"msg": "你好"})的响应头是否含charset=utf-8；Gin v1.9+ 默认不转义中文，不用额外关 escape
标准库 http.ResponseWriter 场景下，优先用 json.NewEncoder(w).Encode(v)
它比 json.Marshal() + w.Write() 更省内存、更早暴露错误，尤其适合大响应或高并发服务。
- 必须提前调
w.Header().Set("Content-Type", "application/json; charset=utf-8")，Encode()不自动设 charset - 必须在
Encode()前调w.WriteHeader(status)（默认 200 可省略），否则状态码可能被忽略 -
Encode()失败会立刻返回 error，比如客户端断连、不可序列化字段，你得捕获并记录，不能忽略返回值 - 别手动设
Content-Length—— 和json.NewEncoder一起用会触发http: response wrote more than the declared Content-Length - 若结构体字段没加
json:"name"tag 或首字母小写，encoding/json 直接忽略该字段，不会报错也不会警告
容易被忽略的底层细节
这些点不报错，但会导致前端解析失败、日志难排查、或线上偶发空响应：
- 中间件提前写了响应（比如某日志中间件调了
w.Write([]byte{})），后续再调json.NewEncoder(w).Encode()会 panic，但错误不明显，只表现为连接重置 - 用
http.Error(w, ...)返回 JSON 错误？它不设 charset，也不走json.Encoder，前端看到的是 text/plain 的错误字符串 - time.Time 字段没加
json:"created_at"`或自定义 MarshalJSON 方法，可能输出为 RFC3339 字符串，也可能因时区问题错乱 - 结构体初始化写成
Data(fruits, vegetables)（函数调用语法）而非Data{Fruit: fruits, Veggies: vegetables}（字面量），编译直接报错：too many arguments to conversion
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
