Iris.OnErrorCode 比中间件更适合全局错误响应，因其在路由匹配失败等底层阶段介入，能捕获404/405等未进入handler的错误；需在app.Run()前注册，支持按状态码独立处理，不自动触发400（需手动设状态码），错误响应可通过ctx.Do()手动注入中间件逻辑。
为什么 iris.OnErrorCode 比中间件更适合全局错误响应？
因为 iris.OnErrorCode 是 Iris 内置的错误码拦截机制，它在路由匹配失败、请求方法不支持、路径不存在等底层阶段就介入，而中间件只能捕获已匹配到 handler 的请求。比如用户访问 /api/v1/unknown，中间件根本不会执行，但 OnErrorCode(404) 一定能捕获。
实操建议：
- 必须在
app.Run()之前注册，否则无效 - 优先级高于任何路由和中间件，适合统一 JSON 错误格式
- 不适用于 handler 内部抛出的 panic（那得靠
app.Use(recover.New())）
OnErrorCode(404) 和 OnErrorCode(405) 怎么区分处理？
Iris 允许为不同状态码注册独立回调，避免用 if 判断混在一起。常见组合是 404（路径未找到）和 405（方法不支持），它们触发条件不同，返回信息也应有差异。
示例写法：
app.OnErrorCode(404, func(ctx iris.Context) {
ctx.JSON(iris.Map{"code": 404, "message": "route not found", "path": ctx.Request().URL.Path})
})
app.OnErrorCode(405, func(ctx iris.Context) {
ctx.JSON(iris.Map{"code": 405, "message": "method not allowed", "allowed": ctx.GetHeader("Allow")})
})
注意：ctx.GetHeader("Allow") 在 405 场景下 Iris 会自动设置该 header，直接读取即可，不用手动推导。
自定义 400 错误（如参数校验失败）要不要走 OnErrorCode？
不要。Iris 不会因 ctx.ReadQuery 或 ctx.ReadJSON 失败自动返回 400 并触发 OnErrorCode(400) —— 这类错误属于业务逻辑层，必须显式调用 ctx.StatusCode(400) 才会激活。
在SEO发布前，从路由清单生成XML网站地图和robots.txt
下载
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
更稳妥的做法是封装校验函数，在 handler 内统一处理：
- 用
ctx.ReadJSON(&v)后检查 error，手动ctx.StatusCode(400).JSON(...) - 或使用
iris.Validator注册结构体校验器，配合ctx.ReadBody自动触发 -
OnErrorCode(400)只建议用于极少数需要兜底的场景（如反向代理透传错误）
如何让错误响应也走中间件（比如加 trace-id）？
OnErrorCode 回调本身不经过常规中间件链，但 Iris 提供了 ctx.Do(iris.Handlers) 方法手动注入。
实操方式：
- 把日志、trace 等公共逻辑抽成独立 handler 函数
- 在
OnErrorCode回调里调用ctx.Do(yourCommonHandlers) - 注意：不能用
ctx.Next()，它只对当前路由有效
例如：
func addTraceID(ctx iris.Context) {
ctx.Header("X-Trace-ID", uuid.New().String())
}
// …
app.OnErrorCode(404, func(ctx iris.Context) {
ctx.Do(addTraceID) // 手动执行
ctx.JSON(iris.Map{"code": 404, "message": "not found"})
})
真正容易被忽略的是：Iris 的错误码处理器没有上下文继承，ctx.Values() 是空的，所有共享数据必须在 Do 阶段写入，不能依赖前置中间件设的值。
