panic: "invalid checksum" 是因zip数据不完整或截断，需先io.readall再zip.newreader；防zip slip须filepath.clean+abs路径校验；大文件应os.open流式处理，避免内存暴涨。
panic: "invalid checksum" 怎么办
这不是你的代码写错了，是 ZIP 数据本身不完整。Go 的 archive/zip 对输入流极其严格，要求字节精确、完整——哪怕少一个字节，zip.NewReader 就直接 panic。
常见于直接拿 http.Response.Body 构造读取器：Body 可能已被其他逻辑消费、提前关闭，或服务端返回了截断响应。
- 错误做法：
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 只是如实反馈
怎么防 Zip Slip（路径穿越）
archive/zip 完全不校验 f.Name，攻击者塞个 ../../../etc/passwd，你一 filepath.Join(dest, f.Name) 就真往系统目录写了。
必须对每个条目做三步处理：
- 先调
filepath.Clean(f.Name)归一化（把./a/../b变成b，../x保持为../x） - 检查归一化后是否仍含
".."，或是否以"/"开头（Windows 下还要统一转小写、把"\"替换为"/"） - 构造目标路径后，用
strings.HasPrefix(filepath.ToSlash(dstPath), filepath.ToSlash(absDest))二次确认没逃出根目录
大 ZIP 文件解压时内存暴涨甚至卡死
OOM 往往不是 archive/zip 的锅，是你自己把整个 ZIP 读进内存了。
- 错误模式：
data, _ := io.ReadAll(zipFile)→ 再丢给zip.NewReader：等于内存里存两份（原始字节 + 解析结构） - 正确方式：用
zip.OpenReader直接打开文件（它自动定位 EOCD，更健壮），内部按需读取，不缓存全文 - 循环中别写
defer rc.Close()—— 所有句柄会堆到函数退出才释放，几百个文件就触发too many open files - 写文件必须用
io.Copy(outFile, rc)，别用io.ReadAll(rc)；它默认 32KB 缓冲，全程零拷贝流式传输
中文文件名乱码或解压失败
ZIP 规范没强制编码，老工具（如 Windows 资源管理器）默认用 GBK 或 CP437，而 Go 默认按 UTF-8 解析 f.Name。
- 优先让上游改用 UTF-8 打包（7-Zip 勾选 “UTF-8”、macOS 默认、
zip -U） - 必须兼容旧包？用
golang.org/x/text/encoding/simplifiedchinese手动 decode：decoded, _ := gbk.NewDecoder().String(f.Name) -
Go 1.22+可尝试f.Header.SetUTF8(true)，但前提是 ZIP 包生成时已设通用位标志（bit 11），否则无效 - 别信
header.Flags = 1能通用解决 —— 这只对压缩有效，解压时不起作用
最常被忽略的其实是三件事：解压前路径校验、解压后 rc.Close() 必须及时调用、大文件必须流式 io.Copy。漏掉任一，轻则乱码、覆盖文件，重则 OOM 或被写入系统关键路径。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
