iris的mvc模式下cors易失效，因mvc路由组（如app.party("/api")）不自动继承根应用中间件，需显式对party调用.use(middleware.cors())，否则控制器路由无法生效。
为什么 Iris 的 MVC 模式下 CORS 容易失效
因为 Iris 的 MVC 结构（如 mvc.Configure(app.Party(...), ...)）默认不自动继承根应用的中间件链。你在 app.Use(...) 注册的全局 CORS 中间件，对 mvc.Application 内部的控制器路由无效——它只作用于手动注册的 app.Get/app.Post 等原生路由。
在 MVC 路由组中显式挂载 CORS 中间件
必须把 CORS 中间件直接加到 MVC 所绑定的 Party 实例上，而不是根 app。常见错误是只写 app.Use(cors.New())，却忘了给 app.Party("/api") 单独配一遍。
-
app.Party("/api")返回的是一个新的子路由器（iris.Party），它有自己的中间件栈 - 正确做法：在
mvc.Configure前，先对这个Party调用.Use() - 示例：
api := app.Party("/api") api.Use(middleware.CORS().Handler()) // ✅ 关键：挂在这里 mvc.Configure(api, func(m *mvc.Application) { m.Party("/user").Handle(new(UserController)) }) - 若需细粒度控制（如仅允许特定 origin），传入自定义配置：
middleware.CORS(iris.CORSConfig{AllowOrigins: []string{"https://myapp.com"}})
使用内置 iris.CORS 还是第三方中间件
Iris v12 自带的 iris.CORS（位于 github.com/kataras/iris/v12/middleware/cors）已足够稳定，无需引入 gin-contrib/cors 或其他兼容层。它支持全部标准字段：AllowOrigins、AllowMethods、AllowHeaders、ExposeHeaders、MaxAge。
- 避免混用：不要同时注册
iris.CORS和github.com/rs/cors，会导致重复响应头或 500 错误 - 调试技巧：用
curl -I http://localhost:8080/api/user检查响应头是否含Access-Control-Allow-Origin - 注意：CORS 配置中的
AllowCredentials: true要求AllowOrigins不能为*，否则浏览器拒绝生效
MVC 控制器里调用 ctx.ResponseWriter().Header().Set(...) 会覆盖 CORS 吗
会。手动设置 Access-Control-* 头属于“后写”，会覆盖中间件前置注入的头，尤其当多个中间件叠加时顺序敏感。Iris 的 CORS 中间件默认在请求早期执行，但如果你在控制器里用 ctx.ResponseWriter().Header().Set("Access-Control-Allow-Origin", "*")，就可能破坏预检（OPTIONS）响应逻辑，导致前端报错 Response to preflight request doesn't pass access control check。
- 绝对不要在控制器里硬编码 CORS 头——这是中间件职责
- 如果需要动态 origin（如从数据库读取白名单），应在 CORS 配置的
AllowOrigins回调函数中处理，而非控制器内 - 检查点：运行时用
app.Logger().SetLevel("debug")查看中间件执行顺序，确认 CORS 是否在 controller 前触发
Use 就完事的，MVC 下真正生效的位置和时机，比直觉中更窄、更具体。漏掉 Party.Use() 这一步，整个 API 组都会静默失败。
