不能只用context.withtimeout(context.background(),…)因为其与http请求生命周期脱钩，无法感知客户端断连或服务优雅关闭，导致超时失效、goroutine泄漏或panic；正确做法是基于ctx.request().context()创建子context并透传。
为什么不能只用 context.WithTimeout(context.Background(), …)
因为 context.Background() 和 HTTP 请求生命周期完全脱钩，你在 controller 里 new 一个新 context，它既不感知请求取消（比如用户关掉浏览器），也不受 Iris 的 ctx.Shutdown 或服务器 graceful shutdown 影响。结果就是：超时没起作用，或超时了但 goroutine 还在跑，甚至引发 panic。
正确做法：用 ctx.Request().Context() 做父 context
Iris 的 iris.Context 底层封装了标准 http.Request，而后者自带 request-scoped context —— 它会在客户端断连、超时、服务关闭时自动 cancel。这才是路由级超时的唯一可靠来源。
实操建议：
- 在 handler 或 controller 方法内，调用
ctx.Request().Context()获取原始 request context - 再用
context.WithTimeout()包一层，例如：ctxReqCtx, cancel := context.WithTimeout(ctx.Request().Context(), 5*time.Second) - 把
ctxReqCtx传给下游耗时操作（如 DB 查询、HTTP 调用、邮件发送） - 务必 defer
cancel()，避免 context 泄漏
别在全局中间件里硬塞超时 context
常见错误是写一个中间件，对所有路由统一加 context.WithTimeout(context.Background(), ...)，然后塞进 ctx.Values().Set("timeoutCtx", ...)。这会导致：
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 所有请求共享同一个 timeout 起始时间，和实际请求到达时间无关
- 无法响应客户端中断，超时后仍继续执行
-
ctx.Values()是 request-scoped，但你塞进去的 context 却不是，语义错位
真正需要统一控制的，应该用 app.UseRouter + ctx.Timeout()（Iris v12.2.5+ 支持），但注意它只影响后续中间件和 handler 的执行时长上限，不替代业务层对 I/O 操作的 context 透传。
带参数的路由（如 /users/{id}）怎么设不同超时？
不能靠路径自动区分，Iris 不提供“按路由 pattern 配置 timeout”的 DSL。你需要手动判断：
- 在 handler 开头用
ctx.Path()或ctx.Params().Get("id")做简单分支 - 对高耗时路径（如导出报表
/reports/export）设 30s；对读接口（如/users/{id}）设 3s - 避免用正则匹配路径，性能差且易出错；优先用已知的固定路径前缀做判断
超时值不是越长越好 —— 它本质是保护你的服务不被慢依赖拖垮。设太短会误杀正常请求，设太长等于没设。真实线上建议从 3s/10s/30s 三级开始灰度观察。
