iris中间件执行顺序由use()调用顺序决定，useglobal()最先执行，ctx.next()位置决定前后置逻辑，options预检需显式路由注册并前置设置响应头。
中间件注册顺序决定执行顺序
Iris 中间件的执行顺序完全由 Use() 调用的先后顺序决定，不是按路由匹配顺序或分组嵌套深度。父分组先 Use()，子分组后 Use()，那最终请求进来时就是“父中间件 → 子中间件 → handler”。
- 所有
Use()都是追加式注册，不会覆盖已注册的中间件 - 同一个
Party上多次调用Use()，会按调用顺序依次执行 -
UseGlobal()注册的中间件永远最先执行（在所有分组中间件之前） - 如果某个中间件里调用了
ctx.StopExecution()，后续所有中间件和 handler 都不会运行
分组嵌套不改变中间件叠加逻辑
所谓“嵌套分组”只是路径拼接的视觉效果，中间件仍是线性叠加。比如 admin.Party("/users") 的中间件，并不会“继承”或“替换” admin 的中间件，而是排在其后执行。
- 错误写法：
admin.Use(auth)，然后又在全局app.Use(logging)——logging会先于auth执行（因为UseGlobal()或提前注册的才靠前） - 正确控制方式：把日志中间件放在最外层
app.Use()，鉴权放admin.Use()，权限细化放users.Use() - 想跳过某一层中间件？不能删注册，得在中间件函数内用
if判断路径或 header 主动ctx.Next()或ctx.StopExecution()
ctx.Next() 的位置影响中间件“前后”行为
ctx.Next() 是中间件能实现“前后包裹”的唯一机制，它代表“继续执行后续中间件和最终 handler”。但它不是自动的，必须显式调用，且位置很关键。
- 放在中间件开头：等价于“前置钩子”，所有逻辑在 handler 前运行
- 放在中间件末尾：等价于“后置钩子”，handler 已执行完，可读取状态码、响应体长度等
- 放在中间件中间：常见于鉴权类中间件，比如检查 header 后调
ctx.Next()，失败则直接ctx.StopExecution() - 切记：一旦调了
ctx.StatusCode()+ctx.WriteString()，再调ctx.Next()就无效了，Iris 不会报错但行为不可控
OPTIONS 预检请求容易破坏中间件链
跨域预检请求（OPTIONS）若没被路由匹配到，中间件根本不会触发；即使匹配到了，如果中间件里把安全头或 CORS 头写在 ctx.Next() 后面，OPTIONS 响应就会漏掉这些头——而浏览器要求预检响应必须包含最终响应应有的头。
- 必须用
app.Options("*", ...)或group.Options("/path", ...)显式注册，确保中间件能跑起来 - 所有安全头（如
X-Content-Type-Options）、CORS 头（如Access-Control-Allow-Origin）都得在ctx.Next()之前统一设置 - 不要写
if ctx.Method() == "OPTIONS" { ... ctx.StopExecution() }就完事，得确保它真进了你写的中间件函数体
ctx.Next()、以及什么时候该用 ctx.StopExecution() 拦住链条——这些细节不试错几轮，光看文档很难踩准。
