go标准库原生支持多文件zip打包，需手动遍历写入且w.close()不可省略，否则zip文件大概率损坏；打包指定文件时须用相对路径、逐个os.open→w.create→io.copy，并严格校验各步错误。
Go 标准库原生支持多文件打包成 ZIP，无需第三方依赖，但必须手动遍历、逐个写入，且 w.Close() 不可省略——漏掉这一步生成的 ZIP 文件大概率打不开。
用 archive/zip 打包多个指定文件
这是最常见场景：已知要压缩的文件路径列表（如 []string{"a.txt", "config.json", "logo.png"}），不涉及目录递归。
- 调用
zip.NewWriter(f)创建写入器后，对每个文件：os.Open()→w.Create(filePath)→io.Copy()写入内容 -
w.Create()中传入的文件名会直接作为 ZIP 内部路径；若传入绝对路径（如/home/user/a.txt），解压时可能越界写入系统目录，务必确保是相对路径或仅文件名 - 每个
os.Open()后应立即defer f.Close()，但注意：多个defer在函数退出时按栈序执行，若文件数多，可能延迟释放句柄；更稳妥的做法是显式f.Close()后再继续循环 - 示例中常忽略错误检查，实际必须判断
os.Open、w.Create、io.Copy的返回值，任一失败都应中断并清理（如删除已创建的空 ZIP）
用 filepath.WalkDir 递归压缩整个目录
想把 /tmp/myapp 整个目录（含子目录和文件）打成 ZIP？标准库没提供一键函数，必须自己遍历。
-
filepath.WalkDir(root, fn)是首选，它比旧版filepath.Walk更安全（不跟随符号链接） - 回调函数中用
d.IsDir()判断跳过目录项，只处理文件；否则w.Create()传入目录名会失败 -
filepath.Rel(root, path)计算相对路径，但 Windows 下返回反斜杠，ZIP 规范强制要求正斜杠/，必须用strings.ReplaceAll(rel, "\", "/")替换 - 空目录不会被
WalkDir回调到，如需保留目录结构（如templates/），得在遍历时额外检测并手动调用w.CreateHeader(&zip.FileHeader{...})，设置ModeDir和结尾/
zip.Writer 的压缩方式与性能影响
默认所有文件都用 DEFLATE 压缩，但你可以控制是否压缩、压缩级别，这对大文件或纯文本很关键。
- 调用
w.Create()会自动启用压缩；若想存为“仅归档不压缩”（类似 tar），需改用w.CreateHeader()并设header.Method = zip.Store - DEFLATE 压缩级别由底层
flate.Writer控制，标准库未暴露直接配置入口；如需精细控制（如牺牲速度换高压缩比），得自己封装flate.NewWriter并传给zip.NewWriter的底层io.Writer - 小文件（
为什么解压后文件权限丢失或路径错乱
这不是 Go 的 bug，而是 ZIP 格式和跨平台路径处理的老问题。
- Linux/macOS 解压时默认不恢复文件权限（
os.FileMode），即使你在zip.FileInfoHeader中设置了Mode()；只有部分解压工具（如unzip -X）支持扩展属性 - Windows 路径分隔符未替换会导致 macOS/Linux 上解压出一堆名为
confconfig.yml的文件（字面含反斜杠），而非进入conf/目录；filepath.ToSlash()虽能转换，但它在 Unix 系统上是冗余操作，语义不如strings.ReplaceAll(rel, "\", "/")明确 -
rel可能为"."（根目录自身），此时w.Create(".")会 panic；务必在调用前加判断：if rel == "." { return nil }
真正容易被忽略的是：ZIP 文件的中央目录必须由 w.Close() 写入，这个步骤不可跳过、不可 defer 在顶层（因 defer 执行时机晚于函数返回），且必须在所有 io.Copy 完成后立刻调用——哪怕只是写入一个空文件，漏掉它，ZIP 就是损坏的。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
