recover必须在defer函数中调用，否则返回nil；需在中间件中统一处理并显式写HTTP响应，且无法回滚副作用，goroutine内panic需各自recover。
recover 必须在 defer 函数中调用，否则返回 nil
API 网关里常见错误是直接在 handler 主体里写 recover()，比如：err := recover() 放在 http.HandleFunc 的函数体开头——这永远得不到 panic 值，recover() 返回 nil。它只在 panic 正在传播、且当前 goroutine 尚未退出时生效，而这个窗口期仅存在于 defer 函数执行过程中。
正确姿势是：每个可能 panic 的 handler 都要包裹一层 defer func()，并在其中调用 recover()。中间件模式更稳妥，避免每个路由重复写。
- 不能在普通函数体、for 循环内、if 分支里直接调用
recover() -
defer必须注册在 panic 可能发生的代码之前（顺序很重要） - 若 handler 内启了新 goroutine，那个 goroutine 的 panic 无法被外层
recover()捕获
HTTP 中间件里 recover 后必须显式写响应，否则连接挂起
网关场景下，recover 成功后若不调用 http.Error() 或 w.WriteHeader() + w.Write()，客户端会一直等待响应，TCP 连接卡在 ESTABLISHED 状态，最终超时或复位。这不是 recover 失败，而是逻辑遗漏。
典型错误写法：recover() 后只打日志、不写 HTTP 响应；或写了但用了 fmt.Println 输出到终端，没触达 response writer。
立即学习“go语言免费学习笔记（深入）”；
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
- 务必检查
recover()分支里是否调用了http.Error(w, "...", http.StatusInternalServerError) - 状态码别硬写 200，panic 属于服务端错误，应统一返回 500 或自定义错误码（如 503）
- 不要依赖 “recover 后函数继续执行” 就默认响应已发出——
http.ResponseWriter不会自动 flush
recover 无法回滚副作用，需配合幂等设计与补偿逻辑
网关里一个请求可能已触发下游调用、写入日志、发消息、修改缓存。recover 捕获 panic 后，这些操作不会撤销。比如：panic 发生在调用支付接口之后、返回结果之前，recover 能防止崩溃，但支付动作已发生。
这时候靠 recover 本身无济于事，得靠架构层面的容错设计：
- 关键操作前生成唯一 trace ID，并记录操作意图（如 “准备扣款 100 元”），便于事后对账
- 下游服务需支持幂等（如带
idempotency-keyheader），避免重复提交 - 对不可逆操作（如发通知、改 DB），把它们拆到异步队列，主流程只做预检和落单
goroutine 隔离不足时 recover 失效，网关必须限制 panic 逃逸范围
API 网关常通过 go 关键字并发处理子任务（如鉴权、限流、日志上报）。若这些 goroutine 内部 panic，外层 handler 的 defer 完全感知不到——recover 仅对同 goroutine 有效。
真实案例：某网关在 go logRequest(...) 里访问了已关闭的 channel，panic 导致整个进程崩溃，因为没人在那个 goroutine 里设 defer。
- 所有显式启动的 goroutine，都必须自带
defer func() { recover() }() - 优先用同步方式处理非核心路径（如审计日志可批量异步，但鉴权必须同步）
- 用
sync.Pool或 context.WithTimeout 控制 goroutine 生命周期，避免泄漏+panic 叠加
recover 在网关里不是兜底银弹，它只解决“单请求不崩进程”这一件事。真正健壮的网关，靠的是 panic 尽量少、副作用尽量可逆、goroutine 尽量可控——recover 只是最后一道缝合线，线太细，拉不住撕裂的架构。
