c.json()返回空或500主因是数据结构不满足json序列化要求：未导出字段（小写首字母）被静默忽略致返回{}；传入func、chan、非字符串键map等不可序列化类型则panic致500。
为什么 c.JSON() 返回空或 500 错误
多数情况不是 Gin 本身问题，而是传给 c.JSON() 的数据结构不满足 JSON 序列化要求。Go 的 json.Marshal() 会静默跳过未导出字段（小写首字母），且无法序列化函数、channel、map 中含非字符串键等类型。
常见错误现象：c.JSON(200, struct{ name string }{"alice"}) 返回 {}；或传入 nil slice、含 time.Time 但没注册自定义 marshaler 时 panic 导致 500。
- 确保结构体字段首字母大写（如
Name而非name） - 对
time.Time字段，加json:"xxx,time_zone=UTC"标签或用json.Marshal前转成字符串 - 避免直接传
interface{}包裹含不可序列化值的 map —— 先做类型断言或白名单过滤
如何正确返回带状态码和自定义 header 的 JSON
c.JSON() 只负责序列化并设 Content-Type: application/json，不控制状态码以外的 header。若需额外 header（如 X-Request-ID）或精确控制状态码逻辑，应改用 c.Data() 或组合 c.Header() + c.Status()。
示例：返回 201 并附带 Location header
c.Header("Location", "/users/123")
c.Status(201)
c.JSON(201, map[string]interface{}{"id": 123, "status": "created"})
- 注意：多次调用
c.JSON()会 panic，因响应体已写入 - 若需动态状态码，先调
c.Status(code)，再c.JSON(code, data)（code 重复传只是冗余，不影响） -
c.Data()更底层，适合你已自己json.Marshal()完毕、想完全掌控输出的场景
处理前端发送的 JSON 请求体时为何 c.BindJSON() 报错
典型错误是 Content-Type 不为 application/json，或请求体不是合法 JSON 字符串（比如多了逗号、单引号代替双引号、BOM 头）。Gin 默认用 json.Unmarshal() 解析，失败时返回 400 并中止后续 handler。
- 检查 curl 是否加了
-H "Content-Type: application/json"，且 body 用双引号 - 结构体字段标签必须匹配 key 名，例如前端传
{"user_name":"bob"}，则字段需写UserName string `json:"user_name"` - 若允许部分字段缺失，字段类型用指针（
*string）或加omitempty标签；否则缺失必报错 - 调试时可在 handler 开头加
body, _ := io.ReadAll(c.Request.Body); fmt.Printf("raw: %s", body)看原始输入
性能敏感场景下要不要避免 c.JSON()
要。每次调用 c.JSON() 都触发一次 json.Marshal()，对高频接口或大数据量（如上万条记录列表）会造成明显 GC 和 CPU 开销。此时应预序列化或用流式响应。
- 对固定结构响应，提前用
json.Marshal()缓存字节切片，handler 中直接c.Data(200, "application/json", cachedBytes) - 对超大数组，改用
c.Stream()+ 分块json.Encoder，避免全量内存驻留 - 注意：缓存 JSON 字节时，若结构体含指针或时间字段，需确认其值在缓存期间不会变化
最易被忽略的是时间字段的序列化一致性 —— 同一个 time.Time 在不同系统时区下可能生成不同字符串，缓存前务必统一转为 UTC 或固定 layout。
