压缩比必须在zip.close()后计算，因central directory和eocd仅此时写入，提前获取文件大小会导致结果虚高；原始目录总大小需用filepath.walkdir()递归统计，且须处理路径分隔符、空目录及元数据影响，确保解压还原度。
压缩比计算必须在 zip.Close() 之后
压缩比 = 原始目录总大小 / ZIP 文件大小，但关键点在于：ZIP 文件大小不能在 w.Close() 前获取。因为 zip.Writer 是流式写入，结尾的 central directory 和 EOCD 记录只在 Close() 时写入，此时文件才真正完整。提前用 f.Stat().Size() 会得到偏小值，导致压缩比虚高。
实操建议：
- 先调用
w.Close()，确保 ZIP 数据落盘 - 再用
f.Stat().Size()获取最终 ZIP 大小 - 原始目录总大小需递归统计（不能只用
os.DirFS(root).ReadDir(".")，它不包含子目录文件） - 推荐用
filepath.WalkDir()遍历时累加d.Info().Size()（跳过目录项）
路径分隔符错误会导致压缩比失真
Windows 下若未处理 filepath.Rel() 返回的反斜杠，某些解压工具（如 macOS Finder）会把所有文件解到同一级，看似“压缩成功”，实则目录结构丢失、解压后无法直接使用——这种 ZIP 包虽体积小，但有效信息已损坏，计算出的压缩比无实际意义。
必须做两件事：
- 对
rel调用strings.ReplaceAll(rel, "\", "/")（不是filepath.ToSlash()） - 跳过
rel == "."的情况，否则w.Create(".")会 panic - 空目录需手动补
zip.FileHeader并设ModeDir，否则解压后目录结构塌陷，影响后续使用体验
别忽略文件元数据占用的空间
ZIP 包里每个文件都有至少 30 字节的 local file header + 46 字节的 central directory entry，加上文件名长度、extra field 等，小文件越多，元数据占比越高。比如打包 1000 个 1KB 的文件，光 header 就占约 76KB，压缩比天然被拉低。
如果你发现压缩比异常差（例如 10MB 目录打成 9.8MB ZIP），优先检查：
- 是否误把日志、缓存等可忽略文件也纳入了遍历（建议用白名单扩展名过滤）
- 是否对每个文件都调用了
fw, _ := w.CreateHeader(header)而非w.Create()，后者会默认用Deflate，前者若没设Method可能退化为Store（无压缩） -
zip.FileHeader.Method是否显式设为zip.Deflate；默认行为在 Go 1.22+ 已改为 Deflate，但旧版本或自定义 header 时仍可能遗漏
真实压缩比要对比解压后还原度
单纯看字节数比值容易误判。例如文本文件压缩率高，但 PNG 图片本身已压缩，再进 ZIP 几乎不减小；而空目录缺失、路径错乱、权限丢失，都会让 ZIP “体积合格”但“不可用”。
验证建议：
- 用
unzip -l out.zip检查路径是否含反斜杠、是否有缺失的目录层级 - 用
zipinfo -v out.zip | grep "compression method"确认是否全为deflate - 解压到临时目录后，用
diff -r对比源目录与解压结果（跳过修改时间）
压缩比数字只是副产品，能正确还原结构和内容才是打包逻辑成立的前提——这点最容易被跳过验证。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
