Gin中动态设置HTTP状态码必须显式调用c.Status()、c.AbortWithStatus()或带状态参数的响应方法（如c.JSON(code, obj)），不可依赖自动推断；c.JSON仅设状态码并序列化，不中断后续逻辑，而c.AbortWithStatus(code)则终止请求链，且所有状态码设定必须在响应体写入前完成。
如何在Gin中动态设置HTTP状态码
不能靠 c.JSON() 或 c.String() 自动推断——它们默认用200，状态码必须显式调用 c.Status()、c.AbortWithStatus() 或带状态的写入方法（如 c.JSON() 的第一个参数）来控制。
常见错误是只改返回体，忘了设状态码，导致前端收到200却解析到错误数据；或者误以为 c.JSON(400, map[string]string{"error": "bad"}) 会自动触发中间件的异常流程，其实它只是发了个400响应，不中断后续逻辑。
-
c.Status(code)只设状态码，不写响应体，适合配合c.Data()或c.Render()手动输出 -
c.AbortWithStatus(code)设状态码并终止当前请求链，适合校验失败后立即退出 -
c.JSON(code, obj)同时设状态码和序列化JSON，最常用，但注意：它不会自动 Abort，后续 handler 仍会执行
Gin里哪些写入方法支持传状态码参数
不是所有响应方法都接受状态码。只有明确设计为“响应+状态码”组合的方法才支持，比如 c.JSON()、c.XML()、c.YAML()、c.ProtoBuf()、c.Render()。而 c.String()、c.Data()、c.File() 等默认用200，需先调 c.Status() 再写内容。
例如：c.String(500, "server error") 是合法的（Gin 1.9+ 支持），但老版本会报错；c.Data(404, "text/plain", []byte("not found")) 在所有版本都有效；c.HTML(200, "index.tmpl", nil) 也支持状态码传参。
- 推荐优先用
c.JSON(code, data)，语义清晰且不易漏设状态码 - 若需复用同一套模板渲染不同状态（如404页和500页），用
c.HTML(code, ...)更直接 - 返回纯文本或二进制时，务必手动调
c.Status(code)，否则状态码永远是200
中间件中统一处理状态码的陷阱
想在中间件里根据 error 类型统一设状态码？小心别覆盖掉 handler 已经写过的响应。Gin 的 c.Writer 不支持“重置状态码”，一旦 c.JSON() 被调用，状态码就已发送给客户端，再调 c.Status() 无效。
正确做法是在中间件里用 c.Next() 后检查 c.Writer.Status()，仅对未写入的状态做兜底（比如 panic 捕获后设500），而不是无条件覆盖。
- 不要在中间件开头就
c.Status(400)—— 这会锁死后续 handler 的状态码选择 - 若用
c.Error(err).SetMeta("status", 401)，需配套自定义 Recovery 中间件读取 meta 并设状态码，否则 meta 不影响 HTTP 状态 - 日志中间件里打印
c.Writer.Status()是安全的，但修改它必须在写响应前
测试动态状态码是否生效的简单办法
别只看返回体内容，用 curl -I 或 Postman 的 Headers 标签确认 Status Line；单元测试里用 httptest.NewRecorder() 检查 w.Code 字段。
示例测试片段：
req, _ := http.NewRequest("GET", "/api/user/1", nil)
w := httptest.NewRecorder()
router.ServeHTTP(w, req)
if w.Code != 404 {
t.Errorf("expected 404, got %d", w.Code)
}
注意：如果 handler 里用了 c.Redirect()，它内部会调 c.Status(302)，但你仍要确保没在 redirect 前调过其他写入方法，否则会 panic：“http: multiple response.WriteHeader calls”。
动态状态码本身不难，难的是和 Gin 的写入时机、中间件生命周期、错误传播路径对齐——状态码一旦发出就不可逆，所以设它的位置，比设什么值更重要。
