全局Recovery中间件不能替代handler内ctx.Recover()，因其仅捕获handler panic，对中间件自身panic无感；ctx.Recover()须置于handler首行、显式判断返回值并调用ctx.StopExecution()阻断执行，且需用fmt.Sprintf("%v", err)安全输出panic值。
全局 Recovery 中间件不能替代 handler 内的 ctx.Recover()，否则 panic 会静默丢弃或递归崩溃。
为什么 iris.Recovery 中间件经常失效
它只捕获 handler 执行时抛出的 panic，对中间件自身 panic 完全无感。实际项目中，panic 高发区恰恰在中间件里：
-
jwt.VerifyToken()解析 token.Claims["exp"] 强转int64失败 - 日志中间件调用
ctx.Values().Get("req_id")返回nil后直接解引用 -
ctx.Next()后续 handler panic，导致 recover 中间件自己也 panic（递归崩溃）
这种情况下，iris.Recovery 不仅没起作用，反而可能掩盖真实崩溃点。
ctx.Recover() 必须放在 handler 第一行
它的机制是单次生效、上下文绑定的：一旦 panic 发生，只有当前 handler 的第一个 ctx.Recover() 能拿到 panic 值；后续再调用就返回 nil，且无法二次捕获。
- 不能包在
if或其他逻辑之后——延迟调用等于放弃捕获 - 必须显式判断返回值，不能忽略：
if err := ctx.Recover(); err != nil { ... } - 调用后若发现 panic，建议立即
ctx.StopExecution()，防止后续逻辑继续执行出错
示例：
<pre class="brush:php;toolbar:false;">app.Get("/api/user/{id}", func(ctx iris.Context) {
if err := ctx.Recover(); err != nil {
ctx.StatusCode(500)
ctx.JSON(iris.Map{"error": "internal server error", "detail": err.Error()})
ctx.StopExecution() // 阻断后续执行
return
}
id := ctx.Params().GetIntDefault("id", 0)
user, err := db.FindUserByID(id)
if err != nil {
ctx.StatusCode(404)
ctx.JSON(iris.Map{"error": "user not found"})
return
}
ctx.JSON(user)
})
panic 值类型不确定，别直接 .Error()
ctx.Recover() 返回的 error 是包装后的值，但原始 panic 可能是 string、error、甚至自定义结构体。Go 的 error 接口要求实现 Error() 方法，而 raw string 不满足——直接调用会 panic。
- 安全做法是先做类型断言：
if s, ok := err.(string); ok { ... } - 或统一用
fmt.Sprintf("%v", err)输出，它能处理任意类型 - 生产环境建议记录完整 panic 堆栈，可用
debug.PrintStack()配合日志系统
最容易被忽略的一点：很多开发者以为加了 iris.Recovery 就一劳永逸，结果线上 panic 日志里只有一行 http: panic serving，根本找不到哪行代码崩的——因为真正该放 ctx.Recover() 的 handler 里，它根本没出现。
