唯一干净可维护的做法是用 app.Party 创建带版本前缀的路由分组并挂载独立 MVC 应用；将版本塞入 query 或 header 会导致日志混杂、OpenAPI 失效、中间件冗余解析、缓存失效等问题。
直接用 app.Party 创建带版本前缀的路由分组，再挂载 MVC 应用——这是唯一干净、可维护、符合 Iris 设计逻辑的做法。
为什么不能把版本号塞进 query 或 header？
常见错误是用 /users?version=v2 或 Accept: application/vnd.myapp.v2+json 区分版本。这会导致：
- 日志里所有请求混在一起，无法按版本归类统计
- OpenAPI 文档生成器无法识别语义差异，v1/v2 接口被当成同一路径重复覆盖
- 中间件逻辑（如鉴权、限流）必须手动解析 query/header，增加出错概率和维护成本
- 缓存策略失效：CDN 或反向代理通常不缓存带 query 的响应
正确做法：Party 分组 + MVC 实例隔离
每个版本对应一个独立的 app.Party，并在其上创建专属 mvc.Application：
- 版本路由必须显式隔离：
v1 := app.Party("/v1")，v2 := app.Party("/v2") - MVC 实例必须绑定到对应分组：
mvc.New(v1).Handle(new(UserV1Controller))，mvc.New(v2).Handle(new(UserV2Controller)) - 不同版本可挂载不同中间件：
v2.Use(auth.OAuth2Middleware)，而v1仍用 JWT - 共享中间件（如日志、压缩）应在
app.Use()全局注册，避免重复写
示例片段：
v1 := app.Party("/v1")
v1.Use(middleware.Logger()) // 共享
mvc.New(v1).Handle(new(UserV1Controller))
v2 := app.Party("/v2")
v2.Use(middleware.Logger(), auth.OAuth2Middleware) // v2 独有
mvc.New(v2).Handle(new(UserV2Controller))
By 参数绑定和 BeforeActivation 在多版本下的注意事项
版本分组后，控制器内 By 参数绑定和 BeforeActivation 行为仍生效，但需注意：
-
By参数只对当前分组内的路径有效；v1.Get("/user/{id:int64}")中的{id:int64}才能触发ById int64注入 -
BeforeActivation注册的自定义路径（如b.Handle("GET", "/profile/{uid}", "Profile")）也只作用于该分组，不会泄漏到 v2 - 若两个版本共用同一控制器结构体（不推荐），需确保方法签名兼容；更稳妥的是为每版定义独立 controller 类型
- 控制器方法名大小写必须严格匹配：v1 用
GetUsers()，v2 改成GetAllUsers()是合法的，但必须在BeforeActivation中显式b.Handle绑定，否则不会自动映射
真正容易被忽略的点是：Party 创建后忘记调用 .Use() 挂载中间件，或 MVC 实例没绑定到 Party 而是直接传给 app，结果 v2 接口完全绕过认证——这种问题上线后极难排查，因为请求能通，只是逻辑裸奔。
