c.json()传入非200状态码时前端收不到响应体，是因为c.status()仅设状态码而不写body、不abort，必须用c.json(400, data)或c.abortwithstatusjson(400, data)等封装方法才能正确返回结构化错误响应。
c.JSON() 传入非200状态码时为什么前端收不到响应体？
因为很多人误以为 c.Status(400) 能像 c.JSON() 那样自动写响应体，其实它只设状态码、不写 body、也不 abort。调完 c.Status(400) 后若没接 c.Writer.Write() 或 c.JSON()，响应就空了。
真正要返回带结构的错误，必须用封装方法：
-
c.JSON(400, gin.H{"error": "bad request"})：一次性写 header + body，推荐用于常规错误 -
c.AbortWithStatusJSON(400, gin.H{"code": 400, "message": "invalid param"})：立即终止中间件链，适合校验失败后快速退出 - 别混用
c.Status(400)和c.JSON(200, ...)—— 后者会覆盖前者，且可能 panic（“write header after body”）
中间件里统一返回自定义状态码和 JSON 结构该怎么做？
重复写 c.JSON(422, ...) 容易漏 abort、状态码不一致、字段不统一。建议封装一个 ErrorResponse 函数：
func ErrorResponse(c *gin.Context, statusCode int, message string) {
c.AbortWithStatusJSON(statusCode, gin.H{
"code": statusCode,
"message": message,
"data": nil,
})
}
使用时注意：
- 必须在调用后加
return，否则后续 handler 仍会执行 - 状态码别硬编码，用
http.StatusUnprocessableEntity这类常量，IDE 可跳转、语义清晰 - 如果需要 trace_id 或 timestamp，从
c.Request.Context()或c.Get("trace_id")拿，别依赖全局变量
动态状态码（比如从 DB 或配置读）传给 c.String() 或 c.JSON() 有哪些坑？
Go 的 c.String() 和 c.JSON() 都接受 int 类型的状态码参数，但 Gin 不做合法性检查 —— 传 -1、999、0 都不会编译报错，但 net/http 底层会写出非法状态行，Nginx/Cloudflare 可能截断或转成 400。
安全做法：
- 用
http.Status*常量兜底，例如statusCode := http.StatusNotFound - 若必须动态，加范围校验：
if statusCode 599 { statusCode = http.StatusInternalServerError } - 别用字符串映射（如
map[string]int{"not_found": 404}），既慢又难维护 -
c.HTML()不支持变量传状态码，只能 if/switch 分支调用：c.HTML(404, "404.html", nil)
返回 499、499 等非标准状态码时要注意什么？
HTTP/1.1 规范没定义 499（Client Closed Request），但 Nginx 常用它表示客户端提前断连。Gin 允许你传 499 给 c.JSON()，但问题在底层：
-
net/http对非标准码不提供 reason phrase，响应头是HTTP/1.1 499（末尾空格），部分客户端解析失败 - 某些代理（如 Cloudflare）会静默转成 400 或丢弃整个响应
- 若必须用，绕过 Gin 封装：
c.Writer.WriteHeader(499)，再手动c.Writer.WriteString(...)，并显式设Content-Type
更稳妥的做法是：用标准码（如 400）+ 明确 message 字段说明“client disconnected”，避免协议层兼容风险。
