应使用 c.AbortWithStatus() 直接返回自定义状态码，它立即终止中间件链且不写响应体；若需 JSON 响应，则用 c.JSON(状态码, 数据) 一次性完成；c.Status() 单独调用易失效，因其仅设待发状态码，未配响应体或 Abort 会导致后续覆盖或 panic。
直接用 c.AbortWithStatus() 返回自定义状态码
Gin 不支持像 net/http 那样在写响应体前随意修改状态码，一旦调用过 c.JSON()、c.String() 等响应方法，Header 就已发送，再改状态码无效。所以必须在写响应体前明确设定。
c.AbortWithStatus() 是最常用也最安全的方式：它立即终止中间件链，并设置状态码且不写任何响应体。适合纯状态码返回场景（比如权限拒绝、资源未找到但不想返回 JSON）。
- 如果只需要状态码，不带响应体，就用
c.AbortWithStatus(403) - 它等价于
c.Status(403); c.Abort()，但更简洁、不易漏掉Abort() - 注意：它不会自动设置
Content-Type，后续若手动写响应体（如c.Writer.Write()），需自行设置 Header
用 c.JSON() 配合 c.Writer.WriteHeader() 控制状态码
当你要返回结构化 JSON 且状态码不是 200 或 201 时，不能只靠 c.JSON(400, data) —— 这个函数内部会先调用 WriteHeader()，但 Gin 的 c.JSON() 第一个参数是状态码，**它确实会生效**，但前提是没被前面的中间件或 handler 提前触发写响应。
真正容易出错的是：你在中间件里调用了 c.Next()，然后在后续 handler 中又调用了 c.JSON(400, ...)，这没问题；但如果中间件里误写了 c.String(200, "...")，那后续再调 c.JSON() 就会 panic：“write header after body”。
立即学习“go语言免费学习笔记（深入）”；
- 推荐写法：
c.JSON(400, map[string]string{"error": "bad request"})—— 状态码由第一个参数决定 - 不要先调
c.Status(400)再调c.JSON(...)，因为c.Status()只设状态码不 abort，后续c.JSON()会再次尝试写 Header，可能冲突 - 如果要复用同一套 JSON 结构但状态码动态变化，直接传入变量：
c.JSON(statusCode, resp)
全局错误处理中间件中统一拦截并改写状态码
很多项目会用 c.Error(err) 把错误注入上下文，再靠 Recovery 或自定义中间件统一处理。这时候状态码往往需要映射：比如数据库约束错误 → 409，校验失败 → 400。
Gin 的 c.Errors 是一个栈，c.Errors.Last() 拿到最后一个错误，但要注意它只是记录，**不会自动影响 HTTP 状态码**，必须手动设置。
- 在中间件末尾检查：
if len(c.Errors) > 0 { c.AbortWithStatus(400) }，但这太粗粒度 - 更合理的是定义错误类型，例如：
type APIError struct { Code int; Message string }，然后在中间件中类型断言：if apiErr, ok := err.(APIError); ok { c.JSON(apiErr.Code, map[string]string{"error": apiErr.Message}) } - 避免在中间件里多次调用
c.JSON()或c.Status()，确保只写一次响应
为什么 c.Status() 单独调用常常失效
c.Status(404) 只是把状态码写进 c.Writer 的 pending header，但 Gin 的响应写入机制依赖「是否已写过 body」。如果你没紧接着写响应体，而后续 handler 又调了 c.String(200, "...")，Gin 会忽略之前设的 404，以新调用的状态码为准。
-
c.Status()必须和响应体写入成对出现，且中间不能有其他响应操作 - 常见陷阱：在 if 分支里只写了
c.Status(404)，忘了加c.String()或c.Abort()，导致流程继续往下走，最终返回 200 - 调试时可打印
c.Writer.Written()判断是否已写响应，值为 1 表示 Header+Body 已发，不能再改状态码
c.AbortWithStatus() 或带状态码参数的 c.JSON()/c.String() 一气呵成**。任何拆成两步（先 Status 再写体）的操作，都得严格保证中间无分支、无 panic、无其他响应调用。 
