recover在图片压缩中用于隔离第三方库因非法输入触发的panic，防止goroutine崩溃导致服务中断，仅对当前goroutine有效，需在独立处理函数内defer调用并配合error返回，不可替代正常错误处理。
为什么图片压缩中需要 recover
图片压缩流程常涉及第三方库（如 golang.org/x/image、github.com/disintegration/imaging）对未知格式、损坏数据或超大尺寸输入的解析，一旦触发 panic（比如解码器遇到非法 JPEG marker、内存分配失败、空指针解引用），整个 goroutine 会崩溃。而 HTTP handler 或批量处理协程若未捕获，会导致服务中断或任务静默失败。这时 recover 不是“兜底万能方案”，而是防止 panic 波及上层调度的关键隔离手段。
注意：recover 只在 defer 中有效，且仅对当前 goroutine 的 panic 生效 —— 它不能跨 goroutine 捕获，也不能恢复已释放的资源（如文件句柄、内存）。它只解决“别让一次坏图搞垮整个服务”这个具体问题。
在 HTTP 图片上传 handler 中安全使用 recover
典型场景：用户上传一张伪造的、头部被篡改的 PNG 文件，image.Decode 内部 panic。你希望返回 400 错误，而不是让 http.ServeHTTP 崩溃。
正确做法是把压缩逻辑包裹在独立函数中，并在该函数入口用 defer + recover 捕获：
func handleImageUpload(w http.ResponseWriter, r *http.Request) {
// ... 解析 multipart/form-data
file, _, _ := r.FormFile("image")
defer file.Close()
// 启动独立函数做压缩，不直接在 handler 里写逻辑
err := compressAndSave(file)
if err != nil {
http.Error(w, "invalid image: "+err.Error(), http.StatusBadRequest)
return
}
w.WriteHeader(http.StatusOK)
}
func compressAndSave(src io.Reader) error {
defer func() {
if r := recover(); r != nil {
// 记录 panic 类型和栈（避免静默丢失信息）
log.Printf("panic during image decode/compress: %v", r)
}
}()
img, _, err := image.Decode(src)
if err != nil {
return fmt.Errorf("decode failed: %w", err)
}
// ... resize, encode, save ...
return nil
}
- 不要在
http.HandlerFunc顶层直接 defer recover —— 它会掩盖真实错误路径，且无法区分是解码 panic 还是网络 write panic - 务必在
compressAndSave内部做recover，确保只拦截图片处理相关 panic - panic 后函数仍会返回（除非显式 panic），所以必须靠
return或 error 传递结果，不能依赖 panic 后自动退出
recover 无法处理的图片压缩失败类型
recover 对以下情况完全无效，需用常规 error 判断：
-
image.Decode返回非 nilerror（如 “unknown format”、“invalid JPEG header”）—— 这是正常控制流，不是 panic - 内存 OOM 导致进程被系统 kill（SIGKILL），Go runtime 不会触发 panic，
recover无感知 - 调用
runtime.GC()或debug.FreeOSMemory()引发的崩溃 —— 属于运行时致命错误，不可 recover - 并发写同一张
*image.RGBA图像导致 data race —— 这会触发 race detector 报告，但不会 panic，更不会被 recover 捕获
也就是说：90% 的图片格式错误、尺寸超限、IO 中断，都走 error 分支；只有极少数底层解码器内部 panic（如某些 Cgo 绑定库未做边界检查）才需要 recover。
Openclaw Auto Recovery
下载
OpenClaw 基础设施心跳监控与自动恢复：部署/卸载心跳守护进程，配置主机监控（Gateway、磁盘、内存、CPU、进程），设置飞书告警，自动重启故障Gateway。适用关键词：心跳监控、heartbeat daemon、服务器告警、自动重启、健康检查、auto recovery。
立即学习“go语言免费学习笔记（深入）”；
压缩流程中 recover 的副作用与取舍
滥用 recover 会让真正该暴露的问题被吞掉。例如：
- 如果
imaging.Resize因传入负数 width panic，说明调用方逻辑有 bug，应修复而非 recover - 如果因
malloc失败 panic，说明单张图太大或并发过高，应限流或调整资源限制，而不是靠 recover 续命 - 日志里频繁出现
runtime error: invalid memory address，大概率是图像指针被提前释放，recover 只是掩盖了 use-after-free
真正值得 recover 的，仅限于你明确知道“输入不可信、库行为不稳定、且 panic 不影响其他请求”的那类边界 case。其余情况，宁可让单次请求失败，也别用 recover 掩盖设计缺陷。
