c.status()仅设置状态码且可重设，不触发响应；c.writer.writeheader()会强制写出http头并可能干扰后续方法。推荐用c.status()或响应方法（如c.json(404, data)）设状态码，并配合c.abort()控制流程。
c.Status() 与 c.Writer.WriteHeader() 的区别
直接调用 c.Status(code) 是 Gin 推荐的设状态码方式，它只写入状态码，不触发响应发送；而 c.Writer.WriteHeader(code) 会强制触发 HTTP 头写出（如果尚未写出），并可能干扰后续 c.JSON() 等方法的自动状态码行为。
常见错误现象：先调 c.Writer.WriteHeader(400)，再调 c.JSON(200, data)，结果返回仍是 400 —— 因为 c.JSON() 不会覆盖已写出的状态码。
-
c.Status()安全、可重设，适合在逻辑分支中动态决定状态码（比如校验失败设 400，成功设 201） -
c.Writer.WriteHeader()应仅在极少数需要绕过 Gin 封装的场景使用（如流式响应、自定义协议头） - 两者都不影响
Content-Type或响应体，状态码和内容需分别设置
在 c.JSON() / c.String() 等方法中传参设状态码
Gin 的多数响应方法（如 c.JSON()、c.String()、c.HTML()）第一个参数就是状态码，它们内部会自动调用 c.Status() 并序列化内容。这是最常用也最不容易出错的方式。
使用场景：handler 中路径清晰、状态码与数据绑定紧密时（例如“查不到用户 → 404 + 错误消息”）。
-
c.JSON(404, gin.H{"error": "user not found"})—— 安全、简洁、语义明确 - 不要写成
c.Status(404); c.JSON(200, ...)，后者状态码会被忽略 - 注意：如果 handler panic 且没被
recovery()拦截，最终状态码是 500，和你前面设的无关
中间件中提前设状态码的风险
在中间件里调 c.Status(401) 后不调 c.Abort()，后续 handler 仍会执行，并可能覆盖状态码（比如返回 200）。这是典型的“设了但没生效”问题。
正确做法是：状态码变更必须配合流程控制。
- 认证失败时：
c.Status(401); c.Abort(); return - 想统一拦截并返回错误，用
c.AbortWithStatusJSON(403, ...)，它等价于c.Status(403); c.JSON(...); c.Abort() - 避免在中间件里只设状态码却不中断流程 —— Gin 不会帮你记住“该返回什么”，它只按最后写出的为准
获取真实响应状态码要读 c.Writer.Status()
日志、监控或审计中间件中，不能用 c.Writer.StatusCode 或 c.status（未导出字段），必须调 c.Writer.Status() 方法 —— 它返回实际已写出或即将写出的状态码（Gin v1.9+ 保证准确）。
容易踩的坑：在 c.Next() 前读 c.Writer.Status()，永远是 0；在 c.Next() 后读，才是最终值。
- 正确顺序：
start := time.Now(); c.Next(); status := c.Writer.Status(); cost := time.Since(start) - 如果 handler 没显式设状态码，
c.Writer.Status()返回 200（默认值） - panic 被
recovery()捕获后，状态码变为 500，此时c.Writer.Status()才反映真实结果
c.Status() 或带码的 c.JSON()）并配以 c.Abort() 控制流程。
