iris.wrapmiddleware 是唯一可行入口，因其将第三方 http.handler 适配为 iris.handler：构造标准 http.responsewriter 和 *http.request 调用 handler，再交还控制权；不可复用闭包，须每次现场调用。
为什么 iris.WrapMiddleware 是唯一可行入口
第三方中间件（比如 gorilla/handlers 或 alice）返回的是 http.Handler，而 Iris 原生中间件类型是 iris.Handler（即 func(ctx iris.Context)）。两者签名不兼容，不能直接传给 Use、UseGlobal 或路由方法。Iris 没有自动类型推导或隐式转换，必须显式桥接。
iris.WrapMiddleware 就是为此设计的——它接收一个 http.Handler，内部用 ctx.ResponseWriter() 和 ctx.Request() 构造标准 http.ResponseWriter 和 *http.Request，再调用该 handler，最后把控制权交还给 Iris 流程。
- 它不是“转换器”，而是“适配器”：不改变第三方逻辑，只补全上下文桥接
- 必须在
WrapMiddleware之后再链式调用Use等，不能直接赋值给变量后反复用（每次调用都新建闭包） - 若第三方中间件依赖
http.ResponseWriter的具体实现（如修改 Header 后立即 write），在 Iris 中仍能正常工作，因为ctx.ResponseWriter()实现了全部http.ResponseWriter接口
常见第三方中间件的 Iris 用法示例
以 gorilla/handlers.CORS 为例，它返回 http.Handler，直接传给 app.Use 会编译报错：cannot use handlers.CORS(...)(nil) (value of type http.Handler) as iris.Handler value in argument to app.Use。
正确写法：
import (
"github.com/kataras/iris/v12"
"github.com/gorilla/handlers"
)
func main() {
app := iris.New()
// ✅ 正确：用 WrapMiddleware 包一层
app.Use(iris.WrapMiddleware(handlers.CORS(
handlers.AllowedOrigins([]string{"https://example.com"}),
handlers.AllowedMethods([]string{"GET", "POST"}),
)))
app.Get("/api/data", func(ctx iris.Context) {
ctx.JSON(iris.Map{"status": "ok"})
})
app.Listen(":8080")
}
-
alice.Chain同理：先alice.New(m1, m2).Then(http.HandlerFunc(...))得到http.Handler，再WrapMiddleware - 不要尝试用
http.HandlerFunc(func(w http.ResponseWriter, r *http.Request))手动包装——Iris 的Context不可从http.Request反向构造，必须走WrapMiddleware - 若第三方中间件需访问自定义字段（如
r.Context().Value("key")），Iris 的ctx.Request().Context()是可用的，但注意生命周期：它和 IrisContext绑定，随请求结束而 cancel
性能与副作用要注意的点
WrapMiddleware 本身开销极小（一次函数闭包 + 接口转换），但桥接过程会触发一次额外的 ResponseWriter 包装和 Request 透传，对 QPS 影响可忽略。真正要注意的是第三方中间件自身行为是否与 Iris 内部机制冲突。
- 日志中间件（如
handlers.LoggingHandler）会输出两份日志：一份来自第三方，一份来自 Iris 自带的Logger——建议禁用其中一个 - 压缩中间件（如
handlers.CompressHandler）和 Iris 的ctx.CompressWriter不兼容，启用后者时应禁用前者，否则可能 double-compress 或 header 冲突 - 如果第三方中间件调用了
http.Error或直接w.WriteHeader+w.Write，Iris 仍能捕获状态码，但响应体可能绕过ctx.Record和模板渲染流程
别踩这个坑：WrapMiddleware 不能跨 app 复用
iris.WrapMiddleware 返回的是一个闭包，它捕获了当前 app 的底层 http.ServeMux 行为逻辑。如果你把同一个 WrapMiddleware(...) 结果存成变量，再用于多个不同 iris.Application 实例，会出现 panic 或静默失效——因为内部依赖的 context.Context 生命周期和中间件注册时机已错位。
- 每次都需要重新调用
iris.WrapMiddleware(handler)，哪怕handler是同一个实例 - 不要在中间件工厂函数里提前 wrap，例如：
func MakeCORS() iris.Handler { return iris.WrapMiddleware(handlers.CORS(...)) }—— 这样写看似简洁，实则埋雷 - 如果要复用逻辑，应封装为接受
iris.Application参数的函数，在每个 app 初始化时单独调用
最稳妥的方式，就是每次都在 app.Use 或 app.Get(...).Handle 的参数位置现场调用 WrapMiddleware。桥接这件事，没有捷径，也不该省略。
