recover无法捕获zip解压流中的panic，因其必须与panic同goroutine且defer需紧邻触发点；标准库zip不panic，问题多源于用户代码的空指针、越界等未检错误。
不能在 Zip 文件解压流中用 recover 做“兜底”——它根本捕获不到解压过程中的 panic，除非你把 recover 显式放在触发 panic 的 goroutine 内部、且紧邻 defer 注册位置。
为什么 Zip 解压流里的 panic 通常 recover 不到
标准库 archive/zip 在读取或解压时遇到损坏数据（如 CRC 错误、超出长度、无效 header），默认行为是返回 error，**不会 panic**。但某些第三方 zip 库、或你自己写的解压逻辑（比如手动解析字段、强制类型断言、越界切片访问）可能触发 panic —— 这些 panic 发生在 io.Copy、z.Read 或循环体内部，而你往往没在那个作用域里放 defer。
- 常见错误：在主函数开头写
defer func() { recover() }()，然后调用extractZip(r)—— 这个recover属于主 goroutine，对子 goroutine 或深层调用栈里的 panic 完全无效 - 更隐蔽的问题：如果你用
io.Copy把 zip.Reader 直接写入os.File或bytes.Buffer，panic 若由底层 write 实现触发（极少见），也不会被外层recover捕获，因为io.Copy是同步阻塞调用，但 panic 仍发生在其内部函数栈，而非你的 defer 作用域 -
recover必须和 panic 在同一个 goroutine，且 defer 必须已注册、尚未执行完毕 —— 解压流通常是线性执行，没有自动为你插入 defer 的机制
真正能生效的 recover 位置：必须贴着解压逻辑写
假设你正在遍历 *zip.ReadCloser 的文件列表并逐个解压，panic 可能出现在：file.Open() 返回 nil 后直接解引用、io.Copy 中传入了已关闭的 writer、手动解析 extra 字段时越界访问 file.Extra 切片。
三层自动备份：每日时间戳快照、次级硬盘镜像、紧急对话导出。
- 正确做法：每个可能出问题的解压单元（比如一个
file的处理）都单独包一层defer - 示例结构：
<pre class="brush:php;toolbar:false;">for _, file := range r.File {
f, err := file.Open()
if err != nil {
log.Printf("skip %s: %v", file.Name, err)
continue
}
// 关键：这里开始新作用域，为本次解压加 recover
func() {
defer func() {
if r := recover(); r != nil {
log.Printf("panic while extracting %s: %v", file.Name, r)
// 注意：f 已打开，必须显式 close
_ = f.Close()
return
}
}()
// 真正解压逻辑放在这里
dst, _ := os.Create(file.Name)
defer dst.Close()
_, _ = io.Copy(dst, f) // 若此处因 f 或 dst 异常 panic，能被捕获
}()
}
- 不要把整个 for 循环包在一个 defer 里 —— 那样 panic 发生时，
file 迭代变量可能已变更，无法定位具体哪个文件出问题 - 每次
recover后，要主动清理资源（如f.Close()），否则文件句柄泄漏
比 recover 更可靠的做法：用 error 替代 panic 场景
绝大多数 zip 解压失败本就不该 panic —— 它们是可预期的输入错误，应该走 error 分支。
- 禁用所有手动
panic("zip corrupt")，改用return fmt.Errorf("invalid zip: %w", err) - 对
file.Extra、file.Comment等切片访问前，先检查长度：if len(file.Extra) >= 4 { ... }，而不是直接file.Extra[0:4] - 用
io.LimitReader(f, file.UncompressedSize64)包裹 reader，防止恶意超大解压消耗内存 - 第三方库若内部 panic，优先换掉或加 wrapper：用
func() (err error) { defer func(){ if r:=recover();r!=nil{err=fmt.Errorf("lib panic: %v",r)} }(); return realCall() }()
容易被忽略的协程陷阱：goroutine + zip 解压
如果为提速把每个 file 丢进独立 goroutine 解压，recover 必须在每个 goroutine 入口处声明 —— 主 goroutine 的 defer 对它们完全无效。
- 错误写法：
go func(){ /* no defer */ }()→ panic 后 goroutine 静默退出，文件句柄、内存不释放 - 正确写法：
<pre class="brush:php;toolbar:false;">go func(file *zip.File) {
defer func() {
if r := recover(); r != nil {
log.Printf("goroutine panic on %s: %v", file.Name, r)
}
}()
// 解压逻辑...
}(file)
- 注意：闭包捕获的是
file 变量地址，循环中直接传 <code>file会导致所有 goroutine 处理最后一个文件 —— 必须传&file或在循环内定义新变量 - goroutine panic 后，
recover能防止崩溃，但无法回滚已写入的临时文件 —— 清理动作（如os.Remove）得在 recover 分支里显式写
真正关键的不是“怎么加 recover”，而是判断哪里可能 panic：zip 库本身极少 panic，问题几乎都出在你的解压逻辑里 —— 类型断言、切片访问、空指针解引用、未检查 error 就继续用值。这些地方加 if 比加 recover 更轻量、更可控、更容易测试。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
