中间件函数签名必须为func(iris.context)，无返回值；ctx.next()不阻断后续代码，需显式调用ctx.stopexecution()终止流程；全局与分组中间件作用域不同；写响应前须检查ctx.isstopped()。
中间件函数签名必须接收 iris.Context，且不能返回值
写一个中间件，本质就是写一个符合框架约定的函数。Iris 要求中间件函数签名严格为 func(iris.Context)，没有返回值，也不接受额外参数。你不能写成 func(ctx iris.Context) error 或 func() iris.Handler —— 这类签名会被忽略或导致编译失败。
常见错误现象：中间件注册后完全不执行，app.Use(myMiddleware) 看似无误，但日志没打、响应没变、甚至 panic 都没触发。原因往往是签名不对，Iris 没法识别它为合法中间件。
- 正确写法：
func(ctx iris.Context) { /* do something */ } - 错误写法：
func(ctx iris.Context) bool { return true }（多返回值） - 错误写法：
func() iris.Context { return nil }（无入参）
ctx.Next() 控制流程，但不会自动阻断后续代码
ctx.Next() 的作用是把控制权交给下一个中间件或最终 handler，但它本身不是“中断指令”。它执行完后，函数体里 ctx.Next() 后面的代码仍会继续运行 —— 这点和 Gin 的 abort() 语义完全不同。
典型踩坑场景：JWT 鉴权中间件中，token 解析失败后调用 ctx.JSON(401, ...)，但末尾忘了加 ctx.StopExecution()，紧接着又写了 ctx.Next()。结果是：错误响应发出去了，但业务 handler 依然被执行，可能造成数据泄露或重复操作。
- 鉴权失败时，必须组合使用：
ctx.StatusCode(401); ctx.JSON(...); ctx.StopExecution() -
ctx.Next()应放在条件分支外、且仅在需要继续流程时调用 - 不要依赖“写完响应就自动终止”——Iris 不做隐式拦截
全局中间件 vs 路由组中间件：注册时机决定作用域
app.Use(...) 注册的是全局中间件，对所有路由生效；而 app.Party(...).Use(...) 或 router := app.Party("/api"); router.Use(...) 注册的是分组中间件，只影响该前缀下的子路由。两者不可互换，选错会导致中间件漏执行或误执行。
使用场景：比如 middleware.CORS() 通常全局注册；而 auth.JWT() 往往只挂载在 /api/v1 下，避免干扰 /public/assets 这类静态资源路由。
- 全局中间件：在
iris.New()后尽早注册，如日志、压缩、recover - 分组中间件：在定义路由组之后、添加具体路由之前注册
- 注意顺序：中间件按注册顺序执行，靠前的中间件可提前终止流程，靠后的可能根本收不到请求
中间件内读写响应需手动管理状态，ctx.IsStopped() 是关键判断依据
Iris 不维护“响应已发送”的内部标记，所以中间件无法通过框架 API 直接得知上一个中间件是否已写响应。你得自己盯住——尤其在链式中间件中，避免重复写状态码或 body。
性能与兼容性影响：重复调用 ctx.StatusCode(200) 或多次 ctx.WriteString() 会导致 HTTP 响应头冲突或 panic（如 header already written）。这不是 bug，是设计使然：Iris 把控制权完全交给你。
- 安全做法：在写响应前先检查
if !ctx.IsStopped() { ctx.StatusCode(403); ctx.WriteString("forbidden") } -
ctx.IsStopped()返回 true 表示ctx.StopExecution()已被调用，或响应已写出（取决于底层 http.ResponseWriter 实现） - 调试时可在中间件开头加
app.Logger().Debugf("middleware: %v, stopped? %v", name, ctx.IsStopped())
中间件开发最易被忽略的点，是默认假设框架会帮你兜底。Iris 的中间件机制极度轻量，几乎没有隐藏逻辑 —— 所有流程控制、状态判断、错误隔离都得你显式编码。写一个能稳定跑在生产环境的中间件，关键不在语法，而在对执行流边界的清醒认知。
