recover不能用于处理文件上传错误，因其仅防goroutine崩溃，而上传失败应通过if err != nil显式处理；真正需recover的场景极少，仅限调用不稳第三方代码时防护，且必须在handler开头defer注册。
recover 不能保护文件上传业务本身，它只能防止 panic 导致整个 HTTP handler 崩溃——但上传逻辑出错（比如磁盘满、权限拒绝、恶意文件）不该靠 panic + recover 来兜底，而应走显式 error 处理。
为什么不能在 upload handler 里依赖 recover 拦截文件错误
文件上传过程中绝大多数失败场景（如 os.Open 失败、io.Copy 写入失败、multipart.ReadForm 解析失败）都返回 error，不是 panic。直接用 if err != nil 判断即可，根本轮不到 recover 出场。
强行把所有上传逻辑包进 panic，再用 recover 捕获，会掩盖真实错误类型、丢失上下文、破坏 Go 的错误处理契约。
- 常见误用：看到
http.Error被跳过，就以为“没捕获到”，于是给io.Copy包一层panic——这反而让本可明确返回500 Internal Server Error的磁盘满错误，变成难以定位的 panic 日志 - 真正该 panic 的极少：比如上传时意外调用了未初始化的
nilmap、解引用空指针、数组越界（这些本就不该出现在上传主路径） -
recover对syscall.ENOSPC（磁盘满）、os.ErrPermission等系统错误完全无效，它们只是error值
什么时候必须在 upload handler 里加 defer+recover
仅当 handler 内部存在无法控制的第三方代码或明显危险操作时，才需防护——例如调用不稳定的 Cgo 封装库、手动解析未知格式的压缩包、或执行用户可控的模板渲染。
OC SSH Tunnel Node Recovery
下载
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
此时 recover 的作用是：不让单个上传请求崩掉整个 goroutine，避免影响其他并发请求。
- 必须写在 handler 函数开头：
defer func() { if r := recover(); r != nil { log.Printf("upload panic: %v", r); http.Error(w, "Internal error", http.StatusInternalServerError) } }() - 不能放在子函数里：比如
func handleUpload() { defer recover() }是无效的，必须在实际执行上传逻辑的那个函数内注册 - 不要试图从
recover中恢复状态：比如 panic 后还继续close(file)或tx.Commit()，此时文件句柄可能已损坏或事务已不可回滚
文件上传真正需要的防护点，和 recover 无关
上传业务的健壮性取决于显式校验与资源管控，不是靠 recover 挡 panic。
- 大小限制必须在读取前生效：
r.ParseMultipartForm(10 或用 <code>http.MaxBytesReader包裹r.Body，否则大文件可能直接 OOM - MIME 类型验证不能只信
Content-Type头：要用fileHeader.Header.Get("Content-Type")结合fileHeader.Size和fileHeader.Open()后读取 magic bytes 校验 - 存储路径必须隔离：永远用
filepath.Join(uploadDir, secureFilename)，禁用用户输入的任何路径片段，防止../etc/passwd类攻击 - 哈希校验要流式计算：在
io.Copy到磁盘的同时，用hash.Hash.Write累加，避免二次读取大文件
recover 后最容易被忽略的副作用
即使 recover 成功，handler 已经执行过的副作用不会自动撤销——这是线上故障的高发区。
- 如果 panic 发生在
io.Copy(dst, src)中途，dst文件可能已写入部分数据，但长度不对；后续若不清理，会留下脏文件 - 若上传逻辑中打开了数据库事务、获取了分布式锁、或向 channel 发送了信号，
recover后不显式 rollback / unlock / drain，会导致资源泄漏或状态不一致 - 日志里看到
Recovered from: runtime error: invalid memory address很容易以为“问题已解决”，但其实那个nilmap 已被并发写入破坏，后续访问同一变量仍会 panic
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
