每个webhook回调goroutine必须独立defer recover，否则panic会导致静默失败；recover后需记录完整上下文、标记失败待重试，并配套监控与重试机制。
Webhook回调里panic会导致整个goroutine退出，必须每个回调单独recover
Go的recover只能捕获本goroutine的panic，而Webhook分发通常是启动新goroutine去处理每个回调（比如go handleWebhook(req)）。如果在handleWebhook里没加defer+recover，一次空指针或JSON解析失败就会让这个goroutine静默死亡，既不返回响应也不记录错误，上游还以为回调成功了。
常见错误是只在main或HTTP handler里加一层recover，指望它兜住所有子goroutine——这完全无效。
- 每个异步回调函数入口必须自己注册
defer func() { recover() }() - 不能把
recover写在调用方（比如分发器），必须落在被go启动的函数内部 - 如果用
sync.WaitGroup等待批量回调，recover失败不会影响wg.Done()，但需确保wg.Done()在defer里或panic前执行，否则goroutine泄漏
recover后必须显式返回错误上下文，不能只打日志
单纯recover()拿到panic值并log.Printf只是第一步。Webhook场景下，你往往需要：把原始请求体、签名头、目标URL、时间戳一并落库标记为“失败待重试”，而不是让它消失。
容易忽略的是：recover之后程序不会自动继续执行原函数剩余逻辑，你得手动控制流程分支。
三层自动备份：每日时间戳快照、次级硬盘镜像、紧急对话导出。
- 不要依赖panic后代码自动续跑，
recover后应立即return或跳转到错误处理路径 - 避免在recover块里再触发panic（比如log时又panic），形成嵌套崩溃
- 若回调涉及HTTP回传（如向第三方确认接收），recover后应主动调用
http.Post发失败通知，而非假设连接还活着
第三方库panic无法预测，recover要覆盖所有可能入口点
Webhook解析常依赖json.Unmarshal、url.Parse、crypto/hmac等，这些在输入畸形时会panic（例如超长字符串触发栈溢出、非法UTF-8字节）。你不能只防自己写的代码，还要覆盖依赖链。
典型漏点：结构体字段tag写错导致json.Unmarshal panic；或用map[string]interface{}解包时对nil map做赋值。
- 在最外层回调函数开头就注册
defer，不要等校验完再加 - 如果用了中间件模式（如自定义
http.Handler），recover必须放在handler.Func内部，而非包装器里 - 对
interface{}类型做类型断言前，先用_, ok := v.(MyType)判断，避免直接v.(MyType)引发panic
recover不等于容错完成，后续重试和监控必须跟上
recover只是让单次回调不崩，不代表问题解决。Webhook失败后，你需要：记录requestID关联原始事件、触发告警、进入重试队列、限制重试次数防止雪崩。
很多人以为加了recover就高枕无忧，结果发现日志里全是“Recovered from: invalid character”，却没人看、没监控、没重试，故障持续数小时。
- recover捕获的panic值建议用
fmt.Sprintf("%v", r)转成字符串存入错误详情字段，保留原始类型信息 - 避免在recover里做耗时操作（如写磁盘、远程调用），应投递到轻量channel或本地队列异步处理
- 监控指标至少包含：每分钟recover次数、各panic类型分布、重试成功率，而不是只看HTTP 200率
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
