http中间件是recover的唯一合理位置，因每个http请求在独立goroutine中执行，recover仅对当前goroutine有效，且中间件是所有请求必经的统一入口；main或handler内recover均无效或不全面。
HTTP handler 中的 recover 必须在中间件或路由函数内显式注册
网关路由（如 Gin 的 gin.Engine、Echo 的 echo.Echo 或原生 http.ServeMux）对每个请求都启动独立 goroutine，recover() 只能捕获当前 goroutine 的 panic。在网关层漏掉 recover，一次 panic("route not found") 就会让整个网关进程退出，所有路由不可用。
实操建议：
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- Gin 用户直接启用内置中间件：
r.Use(gin.Recovery())——它本质就是在每个 handler 执行链末尾插入defer func() { if r := recover(); r != nil { ... } }() - 自定义中间件时，必须把
defer放在next(c)调用之前，否则 panic 发生时defer已执行完毕 - 不要在
http.HandleFunc外层加defer recover()，那只是保护 main goroutine，对请求协程完全无效 - 若使用第三方反向代理（如
gorilla/handlers或自研路由），需确保其HandlerFunc内部已包裹 recover，否则要手动 wrap 一层
子 goroutine panic 会绕过所有 handler 级 recover
网关常在路由中异步处理日志上报、指标采集、鉴权回调、熔断状态更新等逻辑，这些 go func() { ... }() 是独立 goroutine，主 handler 的 recover 对它们完全透明。
常见错误现象：
- 网关看似正常响应，但 CPU 持续 100%，
pprof显示大量 goroutine 阻塞在runtime.gopark - 某次 JWT 解析失败触发
panic("invalid token")，但没被记录，网关静默卡死
实操建议：
- 所有显式
go启动的逻辑，必须用封装函数包裹，例如：safeGo(func() { /* 日志上报 */ })，内部含defer func() { if r := recover(); r != nil { log.WithField("panic", r).Error(...) } }() - 避免在中间件里直接写
go log.Info(...)；改用带 recover 的异步队列（如带 buffer 的 channel + worker goroutine） - 检查你用的 JWT 库、OAuth2 客户端、限流器是否会在回调中 panic——如有，必须在调用点外层加
defer recover()
recover 后不能继续用已破坏的上下文或连接
网关路由中 panic 常源于解析异常 header、非法 query 参数、空指针解引用或并发 map 写入。recover 能阻止崩溃，但无法修复已被破坏的状态：比如 panic 前已向 response writer 写了部分 body，或已修改了 context.Value 中的 auth 字段。
实操建议：
- recover 后立即返回
http.Error(w, "Internal Error", http.StatusInternalServerError)，不要尝试复用w或c继续写入 - 别在 recover 块里调
c.Abort()或c.Next()（Gin）——handler 已处于不可恢复状态 - 若需降级（如 fallback 到缓存路由），必须在 panic **发生前**通过
if err := validate(r); err != nil { goto fallback }主动判断，而不是靠 recover 拦截后跳转 - 记录 panic 时务必带上 traceID：
log.WithField("trace_id", c.GetString("trace_id")).Errorf("panic: %v\n%v", r, debug.Stack())，否则排查无从下手
recover 不等于熔断，网关需额外集成状态管理
单纯 recover 让网关不崩，但无法防止下游服务持续超时、重试风暴或恶意请求打穿限流阈值。高频 panic 往往是下游不可用的信号，此时应主动切换熔断状态，而非仅记录日志。
实操建议：
- 每次 recover 捕获 panic 后，必须调用熔断器的
MarkFailed()（如gobreaker.NewCircuitBreaker(...)），否则失败计数清零 - 路由匹配前先调
breaker.Allow()，返回false就直接http.Error(w, "Service Unavailable", http.StatusServiceUnavailable)，不进业务逻辑 - 别用
hystrix.Do()包裹路由 handler——它不 recover，panic 会直接冒泡；改用hystrix.DoC()，它内部做了 recover 并转为可判断的*hystrix.Error - 熔断器状态变量（
Closed/Open/Half-Open）必须用sync.RWMutex或atomic.Value保护，否则高并发下状态错乱会导致误熔断
真正容易被忽略的是：recover 后的 “继续运行” 常让开发者误以为服务健康，而实际连接堆积、goroutine 泄漏、内存持续增长已在发生。网关的 recover 必须和 srv.Shutdown() 协同——当 panic 频率超过阈值（如 1 分钟内 ≥5 次），应触发优雅下线，而不是硬扛。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
