解压 ZIP 时 panic "invalid checksum" 是因数据不完整或截断，需先 io.ReadAll 再 zip.NewReader；须 filepath.Clean 路径防 Zip Slip；大文件应 os.Open 流式处理，避免内存暴涨。
解压 ZIP 时 panic: "invalid checksum" 怎么办？
这通常不是代码写错了，而是 ZIP 数据本身不完整或被提前截断。Go 的 archive/zip 对输入流极其严格——它要求传入的 io.Reader 必须能提供完整的、字节精确的 ZIP 文件内容。
- 常见于直接用
http.Response.Body构造zip.NewReader：HTTP 响应体可能未读完、被其他逻辑关闭，或服务端返回了不完整响应 - 错误示范：
zip.NewReader(resp.Body, resp.ContentLength)—— 即使ContentLength正确，Body也可能已部分消费或关闭 - 正确做法：先用
io.ReadAll(resp.Body)完整读入内存，再传给zip.NewReader(bytes.NewReader(data), int64(len(data))) - 验证 ZIP 完整性：终端执行
unzip -t yourfile.zip；若报错，说明源文件就损坏，Go 只是如实反馈
为什么解压后文件被写到 /etc/passwd 或 C:Windows？
因为没做路径净化，中了经典的 Zip Slip 漏洞。ZIP 包里的 f.Name 是攻击者可控的字符串，比如 ../../../etc/passwd 或 ....Windowssystem.ini，Go 不会自动拦截。
- 必须对每个
f.Name调用filepath.Clean(f.Name)归一化路径 - 检查净化后是否仍含
".."或以"/"开头（Linux/macOS）或"\"、":"（Windows） - 更稳妥的做法：拼接前先转绝对路径：
absDest, _ := filepath.Abs(destDir)，再构造dstPath := filepath.Join(absDest, filepath.Clean(f.Name))，最后用strings.HasPrefix(filepath.ToSlash(dstPath), filepath.ToSlash(absDest))二次校验 - 跳过目录项要显式判断：
f.FileInfo().IsDir()，否则os.OpenFile会失败
解压大 ZIP 文件时内存暴涨甚至卡死？
archive/zip 本身不缓存整个 ZIP，但你写的代码可能正在干这事。OOM 往往来自误用模式，而非库本身。
- 错误：把几百 MB 的 ZIP 全部读进
[]byte再丢给zip.NewReader—— 这等于内存里存两份数据（原始字节 + 解析后的结构） - 正确：用
os.Open()打开文件，传给zip.NewReader；它内部依赖io.Seeker，只按需读取中央目录和文件块 - 循环中别滥用
defer rc.Close()：在for _, f := range r.File里 defer 会导致所有文件句柄堆积到循环结束才释放，可能触发 “too many open files” - 写大文件时用
io.Copy流式处理，别io.ReadAll(rc)全部加载进内存
中文文件名乱码或解压失败？
ZIP 规范本身不强制编码，老工具默认用 CP437 或 GBK，而 Go 默认按 UTF-8 解析 f.Name。如果 ZIP 是用 Windows 资源管理器或某些旧工具生成的，名字很可能不是 UTF-8。
立即学习“go语言免费学习笔记（深入）”；
- Go 1.22+ 支持设置
r, err := zip.OpenReader("x.zip")后调用r.RegisterDecompressor(zip.Deflate, ...)并启用 UTF-8 标志，但前提是 ZIP 创建时已设header.SetUTF8(true) - 现实 workaround：不要依赖
f.Name直接显示，改用f.FileInfo().Name()（它会尝试从 extra 字段或通用方法还原） - 更稳方案：解压时忽略原始名，用哈希或序号重命名，再通过 ZIP 注释字段或外部 manifest 记录真实名称
- 注意：
filepath.Join()在 Windows 下处理正斜杠没问题，但显示层建议统一用filepath.ToSlash()避免反斜杠混淆
