iris mvc中必须在return前调用ctx.statuscode()显式设置状态码，否则默认为200；顺序颠倒、中间件提前终止或路由未匹配均导致状态码不生效。
控制器里怎么设 HTTP 状态码
在 Iris MVC 中，控制器方法的返回值不会自动影响响应状态码——无论你 return 什么结构体、iris.Map 或 nil，默认都是 200。必须显式调用 ctx.StatusCode() 才能改状态码。
常见错误现象：接口返回了正确 JSON，但浏览器或 curl 显示状态码仍是 200，而你期望是 201、400 或 404。
- 状态码设置必须在
return之前，顺序不能反；写成return data; ctx.StatusCode(400)是无效的 - 如果用了
ctx.JSON()或ctx.Text()手动写响应，ctx.StatusCode()必须在它们之前调用 - MVC 控制器方法签名若为
func(c *X) Get() interface{}，return 值触发自动序列化，此时仍需提前设码
201 Created 和其他非 200 状态怎么组合 JSON
RESTful 接口常用 201 表示资源创建成功，Iris 不会根据返回类型（比如是否含 ID）自动推断，全靠你手动控制。
使用场景：POST 创建用户后返回新用户数据，并设状态码为 201。
- 先调
ctx.StatusCode(201) - 再
return一个可序列化的值，如结构体或iris.Map{"id": 123, "name": "Alice"} - 别用
ctx.JSON()+return混用，否则可能双写响应体导致 panic - 若控制器方法没写
return（比如 void 类型），就必须用ctx.JSON()并配ctx.StopExecution()防止后续逻辑执行
示例：
func (c *UserController) PostCreate() interface{} {
user := User{Name: "Bob"}
// ... save to DB
c.Ctx.StatusCode(201)
return user
}
为什么 404 / 400 有时不生效
最常踩的坑是把状态码设置和路由匹配逻辑搞混：Iris 的 404 响应分两种——框架未匹配到任何路由时的默认 404，和你在 handler 里主动设的 404。后者需要你确保 handler 真的被执行了。
- 路径参数带类型约束（如
{id:uint64}）时，若传入非法值（如负数、字母），Iris 直接返回 404 并不进 controller，你设的StatusCode根本没机会运行 - 中间件（如鉴权）提前
ctx.StopExecution()或ctx.StatusCode(401)后没return，controller 方法仍会执行，造成状态码被覆盖 - 用
panic(&BizError{})触发统一错误处理时，StatusCode由 recover 中间件统一设，controller 内不能再设，否则冲突
统一包装响应时状态码怎么透传
如果你封装了 Success(c *mvc.Controller, data interface{}) 这类工具函数，状态码不能藏在函数内部硬编码——得让调用方决定。
推荐做法是把状态码作为参数传入，或返回一个带状态码的结构体再由顶层统一处理。
- 避免在包装函数里直接调
c.Ctx.StatusCode()，除非你 100% 确认每次都要同一种码 - 更安全的方式是让包装函数只负责组装 body，状态码由 controller 方法自己设，保持控制权清晰
- 若用中间件统一加响应壳（如
{"code":0,"msg":"ok","data":{}}），注意它不能覆盖 controller 已设的状态码，得读取c.Ctx.GetStatusCode()再决定怎么包
真正容易被忽略的是：状态码一旦被框架写入 response header，就无法再修改。哪怕你在 AfterActivation 或 defer 里重设，也晚了。
