c.status()单独调用不生效，因为它只设置响应头状态码而不写响应体、不终止请求链，后续c.json()等会覆盖状态码；正确做法是搭配c.string()/c.json()使用，或直接用c.abortwithstatusjson()一步设码、写体、终止链路。
为什么 c.Status() 单独调用不生效
因为 c.Status() 只设置响应头里的状态码，不写响应体、不结束请求链。如果后续 handler 或中间件又调用了 c.JSON()、c.String() 等方法，它们会覆盖之前的状态码（并自动写入响应体）。所以单独调用 c.Status(404) 后没接任何输出，客户端收到的仍是 200。
真正生效的组合是：
-
c.Status(404)+c.String()/c.JSON()—— 显式设码再写体 - 直接用带状态码参数的方法，比如
c.JSON(404, ...)、c.String(404, ...)—— 一步到位 - 在中间件里用
c.AbortWithStatusJSON(404, ...)—— 设码、写体、终止链路三合一
如何让不同错误类型返回对应 HTTP 状态码
Gin 本身不自动映射业务错误到 HTTP 状态码，得靠你自己判断。常见做法是在中间件里检查 c.Errors 或统一捕获 panic，再根据 error 类型或值匹配状态码。
示例逻辑：
- 遇到
ErrNotFound→ 返回 404 - 遇到
ErrValidation→ 返回 400 - 遇到
context.DeadlineExceeded→ 返回 504 - 其余未识别错误 → 默认 500
注意：c.Errors.Last() 是安全取法，因为 Gin 按顺序追加错误，最新抛出的通常才是业务层真实错误；别用 c.Errors.First()，容易误判。
AbortWithStatusJSON 和 JSON 的关键区别
c.AbortWithStatusJSON() 不只是“带状态码的 JSON 响应”，它还隐含 c.Abort() 行为 —— 终止后续中间件和 handler 执行。而 c.JSON() 不会中断链路，后面代码仍会执行，可能导致重复写响应、panic 或状态码被覆盖。
典型踩坑场景：
- 在鉴权中间件里用
c.JSON(401, ...)+return→ 错！return不阻断链，后续 handler 仍会执行 - 正确写法是
c.AbortWithStatusJSON(401, ...)，或c.JSON(401, ...)+c.Abort() - 若已在中间件末尾调用
c.Next()，就不能再用c.JSON()，否则可能已写过响应体
自定义错误响应结构时状态码怎么塞进去
不要把 HTTP 状态码硬编码进 JSON body 的 "code" 字段里。HTTP 状态码是协议层概念，应由 http.ResponseWriter 写入响应头；body 里的 code 应该是业务码（如 1001 表示“用户名已存在”）。
推荐结构：
{
"code": 1001,
"message": "用户名已存在",
"data": null
}
对应写法：
-
c.AbortWithStatusJSON(http.StatusBadRequest, response)→ HTTP 状态码用http.StatusBadRequest（值为 400），body 里code是业务码 - 避免写成
c.AbortWithStatusJSON(400, map[string]interface{}{"code": 400, ...})—— 混淆协议层和业务层语义
真正容易被忽略的是：HTTP 状态码和 JSON body 中的 code 字段，职责完全不同，混用会让前端解析逻辑和后端排错都变复杂。
