必须显式调用ctx.statuscode()，返回值本身不决定状态码；iris自动序列化仅处理响应体和content-type，状态码默认始终为200，需手动设置且必须置于return之前。
必须显式调用 ctx.StatusCode()，返回值本身不决定状态码。Iris 的控制器函数返回 interface{} 值只会触发自动序列化（如 JSON），但响应状态码始终默认为 200，除非你手动设置。
为什么 return struct 后状态码还是 200？
因为 Iris 的自动序列化机制只处理响应体和 Content-Type，不干预状态码。框架不会从返回值类型、字段名或结构体内容里“猜”你要什么状态码。
- 写
return iris.Map{"code": 404, "msg": "not found"}→ 响应体是 JSON，但状态码仍是 200 - 写
return &User{ID: 1}→ 同样，200 状态码 + JSON body - 想返回 404？必须在
return前加ctx.StatusCode(404)
ctx.StatusCode() 必须放在 return 前，且不能被覆盖
顺序错误会导致状态码失效：Iris 在执行到 return 时才真正写入响应头，此前的 StatusCode 调用会被后续中间件或框架逻辑覆盖（比如日志中间件误设回 200）。
- ✅ 正确：
ctx.StatusCode(404); return iris.Map{...} - ❌ 错误：
return iris.Map{...}; ctx.StatusCode(404)（这行根本不会执行） - ⚠️ 风险操作：在中间件里调
ctx.StatusCode(200)，然后 handler 又调ctx.StatusCode(404)—— 看似 OK，但若中间件在 handler 之后执行（比如用app.UseGlobal），就可能覆盖掉你的 404
常见状态码对应场景和写法差异
不同语义的状态码，除了设码本身，还涉及响应体结构、Header 和是否记录日志：
-
201 Created：用于 POST 创建成功，通常要带LocationHeader：ctx.Header("Location", "/users/123"); ctx.StatusCode(201); return user -
204 No Content：不能带响应体，return nil或ctx.StatusCode(204)后直接return，否则会 panic -
400 Bad Request：建议返回结构化错误信息，但不要暴露参数名或内部字段细节，例如：ctx.StatusCode(400); return iris.Map{"error": "invalid email format"} -
401 Unauthorized/403 Forbidden：注意区分认证失败与权限不足；401 应带WWW-AuthenticateHeader，403 则不用
别依赖 ctx.GetStatusCode() 判断最终状态
这个方法返回的是当前已写入缓冲区的状态码，不是最终发给客户端的那个。它可能被后续中间件修改，也可能还没写入（比如 handler 刚设完，日志中间件还没读）。真正可靠的只有 ctx.ResponseWriter().Status() —— 但它只能在 ctx.Next() 之后调用，适用于日志中间件，不适用于 handler 内部逻辑判断。
实际开发中，状态码决策应在 handler 内明确写出，而不是靠运行时探测。最易忽略的点是：没有把 StatusCode 调用放在所有可能的分支路径上（比如 if/else 里只在一个分支写了，另一个分支漏了，默认就是 200）。
