zip.Writer默认用zip.Store无压缩存储，需显式设FileHeader.Method=zip.Deflate启用DEFLATE压缩；空/小文件可能回退Store；已压缩格式再压无效；解压前须确保ZIP完整，Close()不可遗漏。
zip.Writer写入文件时为什么压缩后体积没变小？
因为 zip.Writer 默认不启用压缩，所有文件都用 zip.Store（即无压缩存储）方式写入。你看到的“压缩包”只是归档，不是真正压缩。
- 必须显式为每个文件设置
FileHeader.Method = zip.Deflate才启用 DEFLATE 压缩 -
zip.Deflate是 Go 标准库唯一支持的压缩方法，不支持 LZMA、ZSTD 等 - 空文件或极小文件（如 <20B）即使设了
Deflate，也可能被自动回退到Store—— 这是底层 zlib 的行为，不是 bug - 文本类内容（JSON、Go 源码等）压缩效果明显；已压缩格式（JPEG、PNG、MP4）再压基本无效，还可能略增体积
解压 zip.ReadCloser 时 panic: "invalid checksum" 怎么办？
常见于从网络流（如 http.Response.Body）直接构造 zip.ReadCloser，但响应体未完整读取或被提前关闭。
- 务必确保传给
zip.NewReader的io.Reader能完整提供 ZIP 文件全部字节 —— 可先用io.ReadAll全部读入内存再解析 - 不要复用同一个
http.Response.Body多次调用zip.NewReader，它是一次性消费的 - 检查 ZIP 是否损坏：
unzip -t yourfile.zip在终端验证；若报错，说明源文件本身就不完整 - 注意：Go 的
archive/zip对 ZIP64 支持有限，超 4GB 或超 65535 个文件时容易出校验失败，优先考虑用github.com/klauspost/compress替代
如何安全地解压到指定目录并防止路径穿越？
直接用 header.Name 构造文件路径会触发 ../../../etc/passwd 类攻击，必须做路径净化。
- 对每个
zip.FileHeader.Name调用filepath.Clean()，然后检查是否仍以".."开头或包含".."路径段 - 更稳妥的做法：用
filepath.Join(目标根目录, filepath.Clean(header.Name))构造路径，再用strings.HasPrefix(绝对路径, 绝对根目录)二次校验 - 跳过目录项（
header.FileInfo().IsDir()为 true）或设备文件（header.Mode()&os.ModeDevice != 0） - 别忽略
header.Mode()权限位 —— Linux 下解压可执行文件需手动os.Chmod，Windows 则基本忽略
用 archive/zip 处理大文件时内存暴涨或卡死？
archive/zip 本身不缓冲整个 ZIP 文件，但常见误用会让 runtime 吃光内存。
立即学习“go语言免费学习笔记（深入）”；
- 避免把整个 ZIP 文件读进
[]byte再丢给zip.NewReader—— 改用os.Open+io.Seeker，它只按需读取目录区和文件块 - 解压时逐个调用
file.Open()并流式写入磁盘，别一次性io.ReadAll(file)到内存 - 压缩大量小文件时，
zip.Writer不会合并写入，每调用一次CreateHeader就产生一个新条目 —— 如果有上万文件，注意 OS 文件描述符限制 - 注意：标准库不支持多线程压缩/解压，CPU 利用率天然单核，高并发场景建议用外部命令（
exec.Command("zip")）或第三方库
最易被忽略的是：ZIP 文件末尾的中央目录结构（Central Directory）必须完整，否则任何语言的解压器都会失败；而 Go 的 zip.Writer.Close() 会自动写入它 —— 如果你忘了调用 Close()，生成的 ZIP 就是损坏的，且毫无提示。
