iris 的 party 优先级高于 controller，因为 party 才是实际绑定路由的单元，controller 仅用于代码组织；注册 controller 必须通过 party.register，其路径前缀与方法注解拼接生效。
为什么 Iris 的 Party 要比 Controller 优先级更高
因为 Iris 的 MVC 并不是传统意义上的“控制器驱动”，Controller 只是结构组织方式，真正绑定路由的是 Party（即路由分组）。你注册一个 Controller，它不会自动挂载任何路径；必须显式调用 app.Party(...).Register(...) 或 .Handle(...) 才生效。
常见错误现象：Controller 方法没被调用、404、方法签名对但始终走不到断点。
- 所有
Controller必须通过Party.Register注册，不能只 new 出来就完事 -
Party的路径前缀会拼接到Controller方法的@Get("/xxx")上，比如app.Party("/api")+@Get("/users")→ 实际路由是/api/users - 若用
Party.Get直接注册函数，和Controller无关——二者是并行机制，别混用还期待自动注入
Controller 方法里怎么安全取 Context 和依赖
Iris 的 Controller 方法参数不是自由写的，框架只识别特定类型：第一个参数必须是 context.Context（或其别名如 iris.Context），后续才能跟自定义依赖（如数据库实例、配置结构体），且这些依赖必须提前通过 app.RegisterValue 或 app.RegisterDependency 注册。
常见错误现象：panic: reflect: Call using zero Value argument、参数为 nil、依赖注入失败。
立即学习“go语言免费学习笔记（深入）”；
- 方法签名必须以
context.Context开头，写成func(c context.Context, db *sql.DB)可以，但func(db *sql.DB, c context.Context)不行 - 未注册的类型（比如直接写
*redis.Client）会导致运行时报错，不是编译期提示 - 如果依赖是接口（如
UserService），注册时要确保传入具体实现，且类型完全匹配（含包路径）
静态资源和模板路径在 MVC 下容易错在哪
模板和静态文件的根路径不是按 main.go 位置算，而是由 app.ConfigureHost 或 app.Run 启动时的当前工作目录决定。MVC 结构里常把 views/ 放在 app/ 子目录下，但 app.RegisterView 给的路径是相对启动目录的，不是相对于 controller 文件的。
常见错误现象：模板找不到（template: "xxx" is undefined）、CSS/JS 404、Render 返回空内容。
- 用
app.RegisterView(iris.HTML("./views", ".html"))时，./views是相对于执行go run main.go的目录，不是main.go所在目录 - 推荐统一用绝对路径：
filepath.Join(filepath.Dir(os.Args[0]), "views")，避免部署时 pwd 不一致 - 静态资源用
app.HandleDir("/static", iris.Dir("./static"))，同样注意路径基准 —— 这里也认启动目录
大型项目里 Controller 分层和复用的硬约束
Iris 的 Controller 不支持嵌套继承或方法重写，所谓“分层”只能靠组合：把公共逻辑抽成独立函数或 service 结构体，再由各 Controller 显式调用。想用 “BaseController” 嵌套字段自动带方法？不行，框架不反射子字段。
常见错误现象：子 Controller 调不了父类方法、this.xxx() 报错、初始化逻辑重复写三遍。
- 不要给
Controller加嵌入字段期望自动获得方法，Iris 不扫描嵌入结构体的方法 - 共享逻辑必须是普通函数或可注入的服务（如
AuthChecker.Check(c)），且每个Controller方法里手动调用 - 路由参数校验、权限检查这类横切逻辑，优先用
Party.Use中间件，而不是塞进每个Controller方法开头
复杂点在于：Iris 的 MVC 是“轻量组织”而非“框架治理”，它不帮你管生命周期、不自动 reload、不隔离依赖作用域。结构越大会越明显——不是语法问题，是设计边界问题。
