Iris MVC需显式设状态码并调用StopWithStatus+JSON终止流程，panic(&BizError{})仅限开发验证；自定义路径须在BeforeActivation中显式注册，参数类型与变量名须严格匹配。
Controller返回值不自动转JSON，必须显式设置状态码
Iris MVC控制器方法的返回值默认不会被框架自动包装成标准响应结构，也不会自动设置HTTP状态码。如果你只写 return user，它会直接序列化为200 OK的JSON，但无法统一加 code/msg 字段；如果想返回400或500，必须手动调用 ctx.StatusCode()，且必须在 return 前执行。
常见错误现象：接口返回空响应、状态码始终是200、前端收不到 code: 40001 这类业务码。
- 控制器方法签名建议返回
interface{}或string，避免返回error（框架完全忽略） - 若需控制状态码，必须注入
iris.Context参数，并在return前调用ctx.StatusCode(n) - 启用 JSON 自动编码只需确保用了
iris.Default()或手动注册了 JSON 编码器，无需额外配置
panic(&BizError{}) 是最简统一错误路径，但仅限开发期快速验证
定义 BizError 结构体并实现 Error() 方法后，用 panic(&BizError{...}) 可触发全局 recover 中间件，快速统一返回格式。但它本质是异常流，不适合生产环境高频使用——堆栈开销大、日志不可控、难以区分系统 panic 和业务 panic。
典型误用：在数据库查询失败时 panic，结果日志里全是冗长堆栈，掩盖真实错误上下文。
- 必须提前注册 recover 中间件，否则 panic 会直接导致进程崩溃
-
BizError类型必须导出且有Error()方法，否则 recover 后无法类型断言识别 - panic 不适用于需要记录请求ID、用户身份等上下文的错误场景
StopWithStatus + JSON 组合才是生产推荐方案
这是 Iris MVC 中真正可控、可调试、可审计的统一响应方式。核心在于：手动设状态码 → 手动写 JSON → 立即中断执行流。
关键约束：ctx.StopWithStatus() 必须紧跟 ctx.JSON() 之后，且后面必须跟 return，否则 controller 剩余逻辑仍会执行，可能造成重复写响应或数据污染。
- 示例写法：
ctx.StatusCode(400); ctx.JSON(BizError{Code: 40001, Msg: "参数错误"}); ctx.StopWithStatus(400); return - 不要省略
return，Iris 不会自动终止方法执行 - 多个分支都要覆盖，比如 if/else 里两边都得写
StopWithStatus，漏一个就可能返回 200 空响应
BeforeActivation 中注册自定义路径时，别依赖方法名自动推导
很多人以为把方法命名为 GetByID 就能自动挂到 /users/{id}，其实 Iris MVC 默认只将 Get、Post 等八种方法名映射到根路径。子路径如 /users/{id:long} 必须在 BeforeActivation 里显式 b.Handle("GET", "/{id:long}", "GetByID")，否则请求根本进不了该方法。
容易踩的坑：路径参数类型写错，比如写成 {id} 而非 {id:long}，导致参数始终为零值，后续校验永远失败。
- 路径参数类型要匹配：整数用
{id:long}或{id:uint64}，字符串用{name:string} - 参数名必须和方法签名中变量名一致，
func(c *UserController) GetByID(id int64)才能接住{id:long} - 同一个 controller 里多个自定义路径，每个都得单独
b.Handle，没有批量注册机制
StopWithStatus 配 return，或者在 BeforeActivation 里漏注册某个路径，结果线上突然冒出一堆 200 空响应或 500 堆栈。 
