可抢救的zip损坏表现为文件头正常但eocd丢失或末尾截断；应优先用zip.newreader流式解析，跳过坏条目提取完好内容，同时严格校验路径防zip slip、手动解码gbk中文名。
如何判断 ZIP 文件是否损坏且还能抢救
直接 zip.OpenReader 报 zip: not a valid zip file 或 io.ErrUnexpectedEOF 不代表全废——关键看错误位置。真正可抢救的损坏通常表现为：文件头魔数 []byte{0x50, 0x4B, 0x03, 0x04} 存在但中央目录（EOCD）丢失、末尾被截断、或某几个文件条目损坏。若 os.Stat 显示文件大小 > 0 且前 4 字节匹配 ZIP 头，就值得继续试探。
用 archive/zip.NewReader 替代 zip.OpenReader 更稳妥：它不依赖 EOCD 定位，而是从开头逐个解析条目，遇到坏条目会返回 zip.ErrFormat，但前面完好的条目仍可读取。
- 先用
os.Open打开文件，再传给zip.NewReader(file, file.Stat().Size()) - 忽略
io.ErrUnexpectedEOF类错误，只当单个条目终止信号，不是全局失败 - 对每个
f调用f.Open()前加defer，避免句柄堆积
修复 ZIP 文件头但别碰中央目录
补上缺失的 0x50 0x4B 0x03 0x04 只能让解压器“认出这是 ZIP”，但无法恢复内容——因为真正定位文件列表的是末尾的中央目录结束记录（EOCD），它包含偏移量和条目总数。强行写入假 EOCD 极易出错：字段顺序、大小端、disk number 全要对，漏一位就彻底失效。
更实际的做法是跳过修复，直接扫描提取：
- 用
io.ReadFull读取文件末尾 22 字节（EOCD 最小长度），检查是否以0x50 0x4B 0x05 0x06开头 - 若没找到，从后往前搜索
0x50 0x4B 0x01 0x02（目录条目签名），估算其大致位置 - 若仍失败，放弃 EOCD 恢复，转用
zip.NewReader流式解析已知完好条目
安全提取未损坏的文件条目
即使 ZIP 结构破损，只要某个 zip.FileHeader 的局部数据完整，就能提取对应文件。重点防两件事：路径逃逸（Zip Slip）和资源泄露。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
路径校验必须分三步走：
- 调用
filepath.Clean(f.Name)归一化路径 - 检查归一化后是否含
".."或以"/"开头（Linux/macOS）；Windows 下统一转小写并替换"\"为"/" - 构造目标路径
dstPath := filepath.Join(absDest, cleanName)，再用strings.HasPrefix(filepath.ToSlash(dstPath), filepath.ToSlash(absDest))确认没越界
遇到 f.IsDir() 为 true 的条目，必须调用 os.MkdirAll(filePath, 0755) —— ZIP 不保证目录条目一定在文件条目前出现。
中文文件名乱码时怎么救
旧 ZIP（尤其 Windows 资源管理器打包）默认用 GBK 编码文件名，而 Go 的 archive/zip 总按 UTF-8 解析，结果就是 ???.txt。不能靠 header.SetUTF8(true)，它只在 Go 1.22+ 有效且依赖 ZIP 包本身设置了 flags 位（bit 1）。
务实解法是手动 decode：
- 引入
golang.org/x/text/encoding/simplifiedchinese - 对每个
f.Name尝试gbk.NewDecoder().String(f.Name) - 若 decode 失败（如返回空或报错），fallback 到原始名或生成安全替代名（如
file_001.txt）
真正麻烦的不是乱码，而是某些条目名字里混着非法字符（如 :、?、*），zip.Writer.CreateHeader 会静默返回 error 却不 panic——这意味着你生成的 ZIP 可能部分条目根本没写进去，但程序还显示“成功”。每次调用后必须显式检查 err。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
