recover必须在HTTP handler首行defer中调用，且需在匿名函数内显式执行；捕获后须手动返回HTTP错误响应、记录完整堆栈，子goroutine需独立recover，不可依赖外层。
recover必须在HTTP handler的defer里调用
网关层的panic如果不捕获，整个goroutine会退出，当前请求直接断连，还可能连带影响连接池复用或超时逻辑。recover唯一有效的写法是在每个handler函数开头就注册defer，且recover必须出现在defer包裹的匿名函数内部。
常见错误是把defer写在handler中间、甚至panic之后；或者把recover挪到单独函数里调用——这会导致返回nil，完全失效。
- 正确位置：handler第一行就写
defer func() { if r := recover(); r != nil { ... } }() - 错误写法：
func handle() { doSomething(); defer func() { recover() }() }（defer太晚） - 错误写法：
func safeRecover() { recover() }+defer safeRecover()（recover不在defer闭包内）
recover捕获后必须显式返回HTTP错误响应
recover本身只是中断panic传播、让函数能继续执行，它不会自动填充http.Error或修改响应状态。如果你只打印日志却不调用http.Error或w.WriteHeader，客户端会一直等待，最终触发超时，网关连接卡住。
典型遗漏点是认为“recover了就等于处理完了”，结果响应体为空、状态码仍是200，下游服务解析失败。
立即学习“go语言免费学习笔记（深入）”；
- 必须在
recover分支里调用http.Error(w, "Internal Server Error", http.StatusInternalServerError) - 如果需要自定义错误格式（如JSON），要手动设置
w.Header().Set("Content-Type", "application/json")再写入body - 避免在recover后继续执行原业务逻辑——panic发生点之后的代码本就不该再跑，强行续跑容易状态错乱
recover无法跨goroutine生效，网关并发场景需特别注意
Go网关常使用http.ServeMux或gin/echo等框架，每个请求默认由独立goroutine处理，所以单个handler里的recover只对本goroutine有效。但如果你在handler里启了新goroutine（比如异步打日志、上报指标、调用下游RPC），这些子goroutine panic了，主handler的recover完全无感。
这类漏捕获的panic会直接终止子goroutine，若没做额外兜底，可能造成资源泄漏（如未关闭的HTTP client连接）或静默失败。
- 子goroutine内必须各自配
defer+recover，不能依赖外层 - 慎用
go func() { ... }()裸启动，优先用封装好的带recover的worker（如go runWithRecover(...)） - 第三方库的回调（如gRPC拦截器、数据库hook）也可能在新goroutine里panic，需查阅文档确认其错误处理模型
recover后不记录panic堆栈等于白加
网关作为流量入口，recover只是让请求不崩，但不记录原始panic堆栈，你就永远不知道问题出在解析header、校验token还是反序列化body。仅打印r（即panic参数）往往信息不足，比如panic("invalid token")看不出调用链，panic(interface {}) {runtime error: index out of range}更没法定位哪行切片越界。
必须配合debug.PrintStack()或runtime.Stack()抓完整上下文，否则线上排查只能靠猜。
- 推荐组合：
log.Printf("PANIC in %s: %+v\n%s", r, r, debug.Stack()) - 避免只记
fmt.Sprintf("%v", r)——丢失类型和字段细节 - 生产环境建议将panic日志单独归类（如level=CRITICAL），并接入ELK或Sentry便于聚合分析
recover不是万能补丁，它只解决“不挂掉”，不解决“为什么挂”。网关里最危险的是把recover当error用，掩盖本该提前校验的业务异常（比如空指针、map并发写）。真正健壮的容错，是recover兜底+结构化error处理+前置防御三者并存。
