必须加recover，因为selectMinConnBackend是高频核心函数，panic会导致goroutine退出和请求静默失败；recover需置于调用方（如HTTP handler、RPC路由、消息消费者）而非函数内部，同时须配合前置防御性校验确保健壮性。
为什么最小连接数算法里要加 recover
因为 selectMinConnBackend 是高频调用的负载均衡核心函数，常被嵌入 HTTP handler、RPC 路由或消息分发逻辑中。一旦内部发生 panic（比如 counters[addr] 访问空指针、backends 为空 slice 导致 range panic），整个 goroutine 会退出，若没捕获，可能造成请求静默失败或连接池状态错乱。这不是“要不要加”的问题，而是“不加就不可靠”。
recover 必须放在调用方，不能塞进 selectMinConnBackend 内部
selectMinConnBackend 本身是纯计算逻辑，不应承担错误恢复职责；它的 panic 应该暴露出来，让上层决定如何降级（比如 fallback 到轮询）或告警。实际加 recover 的位置是它的直接调用点：
- HTTP handler 入口：在
http.HandlerFunc里用defer-recover - RPC 路由器：每个路由 dispatch 前包裹一层保护
- 消息消费者 goroutine：如 RabbitMQ 消费循环中，每个
msg处理前加保护
示例：
func handleRequest(w http.ResponseWriter, r *http.Request) {
defer func() {
if r := recover(); r != nil {
log.Printf("panic in load balancing: %v", r)
// 此处可 fallback 到 backup backend 或返回 503
http.Error(w, "backend selection failed", http.StatusServiceUnavailable)
}
}()
backend := selectMinConnBackend()
// 后续转发逻辑...
}
容易踩的坑：recover 不会捕获 goroutine 外部 panic
如果 selectMinConnBackend 被用于启动新 goroutine（比如并发探测多个后端健康状态），而你在主 goroutine 加了 recover，那是无效的——子 goroutine panic 不会传播上来。
3-Tier Auto-Backup Daily Snapshots, Drive Mirror & Emergency Recovery
下载
三层自动备份：每日时间戳快照、次级硬盘镜像、紧急对话导出。
立即学习“go语言免费学习笔记（深入）”；
- 每个独立 goroutine 都需有自己的
defer-recover，尤其在go func() { ... }()内部 - 不要依赖全局 panic handler：Go 没有类似 Node.js 的
uncaughtException机制 - 注意
recover()只在 defer 函数中有效，且仅捕获当前 goroutine 的 panic
更稳妥的做法：提前防御，比 recover 更重要
真正健壮的负载均衡器，recover 是最后一道防线，不是替代校验的手段。必须前置做这些检查：
- 初始化时确保
backends非空，counters已为每个地址初始化*atomic.Int64 - 在
selectMinConnBackend开头加 guard：if len(backends) == 0 { return "" } - 对
counters[addr]访问前，先确认addr是否存在于 map 中（避免零值指针 dereference） - 所有外部输入（如动态更新的 backend 列表）必须带锁或原子操作更新，防止读写竞争导致 panic
recover 解决的是“万一出事怎么不崩”，而防御性编程解决的是“不让它出事”。后者漏掉一个判断，前者就得天天修告警。
