用 archive/zip 打中文路径需设 Flags=0x800 启用 UTF-8 标志或改用 ASCII 路径；archive/tar 需手动设置 Mode 保留权限，避免 Uname/Gname 导致属主问题；Zip 适合终端分发，Tar+gzip 适合流式构建；务必按序 close writer。
用 archive/zip 打包文件时，中文路径乱码怎么办
Go 默认用 UTF-8 写入 zip 文件名，但 Windows 资源管理器和部分旧版解压工具默认按 GBK 解码 —— 这不是 Go 的 bug，是 zip 规范历史包袱导致的兼容性问题。
实操建议：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 如果目标用户主要是 Windows 且用系统自带解压，改用
github.com/mholt/archiver/v4（它自动处理ZipFileHeader.Flags = 0x800启用 UTF-8 标志） - 若坚持用标准库，必须手动设置
zip.FileHeader.Name为 ASCII 路径（比如用拼音或下划线替代中文），否则别指望资源管理器能正确显示 -
zip.FileHeader.Comment不受此限制，可放心存中文说明
archive/tar 打包时权限丢失、所有者变成 root
Tar 本身不存储 Windows 权限，但在 Linux/macOS 下，tar.Header 的 Mode 和 Uname/Gname 字段控制权限与归属。Go 默认用 0644 和空用户名，所以打包后解压出来全是普通文件、属主是当前用户（非 root），除非你显式写错。
常见错误现象：本地打包再解压，发现 chmod +x 的脚本没了执行权限；或者 CI 环境里用 root 打包，结果 tar 包里 Uname 是 "root"，别人解压后文件属主也变成 root。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 设置
header.Mode时，别直接传os.FileInfo.Mode()，要先 & 0755（去掉 setuid/setgid 等位，避免 tar 兼容问题） - 如需保留可执行位：
header.Mode = fileInfo.Mode() & 0755 | 0o100000（加 file bit） - 不要设
header.Uname/Gname，除非真有跨用户分发需求；设了反而容易在非 root 环境触发chown: operation not permitted
Zip 与 Tar 性能差异：什么时候该选哪个
Zip 是随机访问格式，支持单文件解压、校验和内建；Tar 是纯流式归档，无压缩、无索引、依赖外层 gzip/xz。两者根本不是同一层的东西 —— archive/zip 包含压缩逻辑，archive/tar 只管打包，压缩得自己套 gzip.Writer。
使用场景判断：
- 要给终端用户下载一个带目录结构的安装包？用
archive/zip，Windows/macOS/Linux 原生支持，双击就能开 - 做容器镜像层、CI 构建产物归档、或后续要管道传输给
gzip -c？用archive/tar+gzip.Writer，内存占用低、流式写入不卡顿 - 需要加密？两个包都不支持，得上
golang.org/x/crypto/nacl/secretbox或外部工具
写入 tar.gz 时卡住或生成空文件
这是最常踩的坑：忘了调用 tw.Close() 和 gw.Close()。tar/gzip 是多层 writer，每层 close 都会 flush 缓冲区并写 footer —— 少一次 close，gzip 流就不完整，解压时提示 invalid compressed data -- format violated 或直接截断。
实操建议：
- 用
defer按相反顺序 close：defer gw.Close(); defer tw.Close(); defer f.Close() - 别在循环里反复
tw.WriteHeader()后立刻tw.Write()，大文件要分块读写，否则 OOM - 检查
os.Open()返回的fileInfo.Size()是否为 0，空文件会导致tw.WriteHeader()后没内容可写，但不会报错
真正麻烦的是混合场景：既要中文路径兼容性，又要流式压缩，还得保持权限。这时候标准库就有点吃力，得考虑封装一层或换成熟库 —— 但先确认你的需求到底是不是真的需要同时满足这三点。
