Iris 500 错误处理器需在路由注册前调用且必须显式设状态码；禁止返回 panic 信息，应记录日志并返回友好文案；自定义 500 模板须确保可独立渲染，避免嵌套崩溃。
必须在路由注册前调用 app.OnErrorCode
500 错误处理器不会生效，最常见的原因是注册顺序错了。Iris 的错误处理是“静态绑定”，app.OnErrorCode(iris.StatusInternalServerError, handler) 必须在 app.Get、app.Post 等任何路由注册之前执行，且要在 app.Run() 之前。如果写反了，请求会直接落入默认 panic 捕获逻辑，你的函数根本不会被调用。
ctx.StatusCode(500) 这一行不能省
Iris 不会自动设置状态码，即使你绑定了 500 处理器，响应头仍可能是 200。浏览器或爬虫可能缓存这个错误页面为成功响应，导致 SEO 或调试异常。必须在 handler 开头显式调用：
func handle500(ctx iris.Context) {
ctx.StatusCode(500) // 关键！
ctx.View("errors/500.html")
}
漏掉这行，页面内容看起来正常，但 HTTP 状态码不对——这是线上排查时最常忽略的点。
别把 panic 信息直接返回给前端
500 是服务端内部错误，不是用户该看到的细节。常见错误包括：
- 在 handler 里调用
ctx.JSON(err)或ctx.Text("%v", err)，暴露堆栈或敏感路径 - 没做 recover，panic 直接穿透到 Iris 默认崩溃页（带完整 goroutine dump）
正确做法是：统一返回友好文案（如“服务暂时不可用”），同时用 app.Logger().Errorf 记录完整错误和堆栈到日志文件。若需定位问题，靠日志，不靠响应体。
模板渲染失败会导致 500 嵌套 500
如果你的 errors/500.html 模板本身有语法错误（比如变量名拼错、嵌套标签未闭合），Iris 渲染时会再次 panic，触发默认崩溃页，形成“自定义 500 → 渲染失败 → 默认 500”的循环。验证时务必先单独访问该模板路径（如加个临时路由 app.Get("/test-500", func(c iris.Context) { c.View("errors/500.html") })），确认它能独立渲染成功。
