fiber 的 fiber.timeout 中间件无效，已弃用；必须在 handler 开头调用 c.context().setdeadline() 设超时，且需按下游服务隔离配置，超时后需手动检查 deadlineexceeded 并立即返回。
Timeout中间件在Fiber里根本不能用
Fiber 的 fiber.Timeout 中间件是假的——它只是个空壳，底层没实现任何超时逻辑，调用后既不设 deadline 也不 cancel ctx，压测时完全失效。官方文档里还留着它，但源码里早被标记为 deprecated（2026 年 9 月起所有 v2.5+ 和 v3.x 版本均不生效）。别在 app.Use(fiber.Timeout(...)) 上浪费时间。
必须手动调用 c.Context().SetDeadline()
fasthttp 的 context 不兼容标准 context.WithTimeout，c.Context().Done() 永远不会触发，唯一可靠方式是在 handler 开头显式设 deadline：
-
c.Context().SetDeadline(time.Now().Add(2 * time.Second))是唯一生效路径 - 必须放在 handler 函数最开始，不能塞进中间件统一处理——因为每个请求的
c.Context()是独立实例，中间件里设的 deadline 对后续 handler 无效 - 外部调用（DB、HTTP client、Redis）前再设一次 deadline 更稳妥，避免 handler 内部耗时掩盖下游阻塞
路由级超时要按下游服务隔离写
不同下游服务响应能力差异大，统一 timeout 是反模式。比如 /api/users 走 PostgreSQL，/api/search 走 Elasticsearch，超时阈值必须分开：
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
-
GET:/api/users/:id→ 设 1.5s（DB 查询 + 序列化） -
POST:/api/search→ 设 3s（ES 聚合可能慢） - 别用通配路由
app.Get("/api/*", timeoutMW, handler)，它会把所有子路径强行套同一 timeout，导致 /api/health 也被卡 3s - 真要复用逻辑，用闭包封装 deadline 调用：
timeoutHandler(2*time.Second, userHandler)，而不是注册中间件
超时后 fasthttp 不会自动关闭连接
SetDeadline 触发后，c.Context().IsBodyStream() == true 时，如果 handler 已开始写响应（比如已调 c.Status(200)），fasthttp 不会中断 TCP 连接，客户端会一直等 body 流完或超时断连。容易造成：
- P99 延迟虚高（实际是客户端等超时）
- 连接池堆积（连接未释放）
- 日志里看不到 “timeout” 错误，只有 “client disconnected”
补救措施：handler 内检查 c.Context().DeadlineExceeded()，一旦为 true 就立即 return，不写任何 body；同时确保 DB/HTTP client 层也设了对应 deadline，避免 goroutine 卡死。
