Iris框架异常中间件开发实例-Golang-PHP中文网

iris 默认 panic 会终止整个 http server，因其无自动 recover 机制且每个请求在独立 goroutine 中执行；必须手动前置注册 iris.recover 中间件，并可自定义错误响应体，但 recover 仅兜底未预期 panic，不能替代业务层错误处理。

iris框架异常中间件开发实例

Iris 没有自动 panic 捕获机制，不加 recover 中间件时，任何未处理 panic 都会导致整个 HTTP server 崩溃退出。

为什么默认 panic 会杀掉整个服务

Iris 的 ctx.Next() 只在当前 goroutine 内有效，它不会自动包装 handler 函数做 recover。Go 的 panic 默认只被当前 goroutine 捕获，而每个 HTTP 请求由独立 goroutine 处理——如果 handler 内部 panic 且没被拦截，该 goroutine 就终止，但 Iris 不会主动 recover，最终进程收到未捕获 panic 后直接退出。

常见触发点：数据库查询返回 nil 后直接解引用、json.Unmarshal 传入未初始化结构体指针、调用空接口方法等。

别依赖 iris.Default() 自带 recover —— 它只是个快捷封装，实际仍需显式启用
所有自定义中间件、handler、甚至模板渲染中都可能 panic，必须统一入口拦截
日志里看到 panic: runtime error: invalid memory address 并伴随服务重启，基本就是漏了 recover

recover 中间件必须手动注册且放最前

中间件执行顺序决定 recover 能否生效：app.Use(iris.Recover) 必须在 app.Get 等路由注册之前调用，否则 panic 发生在中间件链之外，recover 根本不执行。

错误写法示例：

app.Get("/api/user", handler)
app.Use(iris.Recover) // ❌ 生效不了，路由已注册完

正确结构：

Iris框架 12.2.5

Iris框架 12.2.5 版本源码包下载，适合需要 MVC Singleton 控制器、依赖注入字段控制和 debug 错误日志改进的开发者。

下载

始终把 app.Use(iris.Recover) 放在 app.Get/app.Post 之前
若用了分组（app.Party("/api")），需在分组对象上调用 Use，而非根 app
不要自己写裸 defer func() { if r := recover(); r != nil { ... } }() —— iris.Recover 已处理日志、状态码（500）、响应格式化，重复造轮子容易漏掉 Content-Type 或响应体

自定义错误响应体要兼容前端解析

iris.Recover 默认返回纯文本 "Internal Server Error"，前端 fetch 时 response.json() 会失败。需要替换其内部的错误处理器。

实操方式是传入自定义函数：

app.Use(iris.Recover(func(ctx iris.Context, err interface{}) {
    ctx.StatusCode(500)
    ctx.JSON(iris.Map{
        "code": 500,
        "message": "Internal server error",
        "detail": fmt.Sprintf("%v", err),
    })
}))