用Party做版本前缀分组是唯一原生支持的方式，需显式注册v1/v2路由且路径参数类型必须统一，中间件顺序固定，静态资源与错误页须在所有Party注册后配置。
用 Party 做版本前缀分组是最直接有效的方式
Iris 没有自动多版本同步机制，所谓“v1/v2 一键继承”是不存在的。必须显式调用 app.Party("/v1") 和 app.Party("/v2") 分别注册路由。这是唯一被框架原生支持、且不会引入隐式行为的方式。
常见错误是试图在 v1 分组里注册一个通用 handler，再指望它自动出现在 v2 下——这会导致 /v2/xxx 404。每个版本的路由都得单独写一遍，哪怕逻辑完全相同。
示例中这样写才安全：
v1 := app.Party("/v1")
v1.Get("/user/{id:uint64}", userHandler)
v2 := app.Party("/v2")
v2.Get("/user/{id:uint64}", userHandler) // 必须重复注册
路径参数类型不一致会导致跨版本 404 或 panic
路径参数类型必须显式声明，{id} 和 {id:uint64} 在 Iris 路由树中是两条完全不同的路径。如果 v1 用的是 {id}（字符串），而你在 v2 中改用 {id:uint64}（强类型），那么 v1 的请求仍走 v1 分组，但 v2 的请求会因类型不匹配直接 404；反之，若 v1 未声明类型却调用 ctx.Params().GetUint64("id")，则 panic。
- v1 路由写成
/user/{id}→ctx.Params().Get("id")安全，GetUint64会 panic - v2 路由写成
/user/{id:uint64}→GetUint64安全，但 v1 的同名路径无法复用该 handler - 若想共用 handler，两个版本都得统一为
{id:uint64}，否则类型校验和路由匹配都会出问题
中间件执行顺序固定，版本分组不隔离全局中间件
在 app.Use(authMiddleware) 后再调用 v1.Use(versionV1Only)，实际执行顺序是：全局中间件 → v1 专属中间件 → handler。v1 的 Use 不会覆盖或跳过全局中间件，只是追加。
容易踩的坑：
- 误以为
v1.Use()能屏蔽app.Use()—— 实际不能 - 权限类中间件忘记调用
ctx.StopExecution()，导致鉴权失败后仍继续执行后续 handler - 跨版本共享逻辑（如统一响应包装）重复写在每个
Party里，而不是抽到app.UseGlobal()或独立中间件包中
静态资源与错误页必须放在所有 Party 注册之后
像 app.HandleDir("/public", "./public/") 或 app.OnAnyErrorCode() 这类兜底路由，如果插在 app.Party("/v1") 和 app.Party("/v2") 中间，可能被某个分组的 Use() 干扰，或者因匹配优先级过高而截断 API 请求。
唯一安全的位置是：所有 Party 注册完成之后、app.Run() 之前。
复杂点在于错误页定制：v1 返回纯 JSON 错误，v2 要带 traceID 结构体。这时不能靠路由分组控制，得在 OnAnyErrorCode 里手动检查 ctx.Request().URL.Path 前缀再分支处理。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
