Iris不支持子应用概念，强行模拟会导致路由冲突、中间件失效、ctx生命周期错乱；正确做法是用Party+路径前缀实现逻辑隔离，或物理分离进程并用反向代理分发。
Iris 不支持子应用（SubApp）概念，强行模拟会导致路由冲突、中间件失效、ctx 生命周期错乱。Iris 的设计哲学是单实例、单路由树，所谓“挂载子应用”在官方文档和源码中均无对应机制。常见错误是用 iris.New() 在子包里新建一个 Application 实例再试图“注册”到主 app 上——这只会创建独立的 HTTP 服务监听器，或 panic 报错。
为什么 iris.New() 不能用在模块里
每个 iris.New() 都会初始化一套完整的路由树、中间件栈、日志器和服务器配置。若在 routers/admin.go 中写 subApp := iris.New()，它和主 app 完全隔离：
- 中间件（如
authMiddleware）不会自动继承，subApp.Use()对主 app 无效 -
subApp.Get("/dashboard")启动的是另一个独立服务，默认监听 :8080，和主 app 冲突 - 若尝试用
app.Any("/*path", subApp.Handler())转发，会丢失Context元数据（如ctx.Values()、ctx.Params()），且无法正确处理 WebSocket 升级、文件上传等协议细节
替代方案：用 Party + 前缀路径实现逻辑隔离
真正可行的做法是复用主 Application 实例，通过 Party 划分路由作用域，并显式挂载中间件：
- 所有子模块必须接收
*iris.Application或iris.Party作为参数，禁止自行 new - 用路径前缀定义边界，例如
adminAPI := app.Party("/admin")，而非 “启动 admin 子服务” - 中间件在
Party创建时传入，或后续调用.Use()，确保只作用于该前缀下的所有子路由 - 静态资源、模板等全局依赖仍由主 app 统一管理，避免路径错位导致 404
示例：routers/admin.go
func SetupAdminRoutes(app *iris.Application) {
adminAPI := app.Party("/admin")
adminAPI.Use(authMiddleware, csrfMiddleware)
adminAPI.Get("/", dashboardHandler)
adminAPI.Post("/users", createUserHandler)
}
需要完全隔离场景怎么办
如果业务上真有强隔离需求（如多租户、不同团队维护不同 API 域），应物理分离进程：
- 拆成多个独立可执行文件（
admin-api、user-api），各自iris.New()+iris.Listen() - 用反向代理（Nginx/Caddy）按 path 前缀分发请求：
/admin/ → http://127.0.0.1:9001，/api/ → http://127.0.0.1:9002 - 共享中间件逻辑抽成函数，各子服务单独调用，不共享内存态（如 JWT key、数据库连接池需各自初始化）
最易被忽略的一点：Iris 的 Party 不是“子应用”，它只是路由前缀 + 中间件作用域的语法糖。所有 Party 最终都注册进同一个 Application.router.APIBuilder，不存在嵌套或层级继承。混淆这个概念，就会掉进中间件不触发、参数解析失败、日志丢失的坑里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
