Go压缩ZIP中文乱码需手动设fh.Flags|=0x800并确保UTF-8文件名；tar体积大因纳秒时间戳和绝对路径；解压前须判断IsDir；并发压缩应预读文件而非并发写入；跨平台注意路径与权限映射。
zip压缩时中文文件名乱码怎么办
Go 默认用 CP437 编码写 zip，Windows 和 macOS 解压时看到中文名变成 .txt，不是文件内容坏了，是文件名编码没对上。
根本原因是 archive/zip 不支持 UTF-8 文件名（ZIP Spec 6.3.4 要求设置 FileHeader.Flags 第11位），而 Go 标准库没自动设这个标志。
- 手动设置
fh.Flags |= 0x800，再用utf8.DecodeRuneInString确保文件名是合法 UTF-8 - 不要依赖
filepath.Base直接塞进fh.Name——它可能含\或非法控制字符 - 解压端（比如 Windows 资源管理器）是否显示正常，取决于它是否识别 ZIP 中的 UTF-8 标志；7-Zip、macOS 归档实用工具通常 OK，但老版 WinRAR 可能忽略
tar.gz 打包后体积比预期大很多
不是压缩算法问题，大概率是 os.FileInfo 拿到的 ModTime 带纳秒精度，而 archive/tar 写 header 时会把完整时间戳存进去，导致 tar 文件本身变大（尤其小文件多时）；更隐蔽的是，tar.Header 的 Name 如果带绝对路径或 ../，某些解压工具会拒绝或跳过。
- 打包前统一截断时间：
fi.ModTime().Truncate(time.Second) -
tar.Header.Name必须是相对路径，用strings.TrimPrefix(fi.Name(), rootDir)清洗，别留开头的/ - 如果目标是兼容性优先（比如要给 BusyBox ash 解压），用
tar.FormatUstar替代默认格式，避免 GNU 扩展字段
解压 zip 时 io.Copy 报 invalid argument
常见于从 zip.File.Open() 得到的 io.ReadCloser 直接传给 io.Copy 写入新文件，但没检查 zip.File.IsDir()，结果试图把目录当成文件读——底层系统调用返回 EINVAL，Go 就包装成 invalid argument。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须先判断
f.FileInfo().IsDir()，目录就os.MkdirAll，不调f.Open() - 注意
zip.File的FileInfo()返回的是虚拟信息，Size()对目录恒为 0，不能用来跳过 - 如果 zip 里有符号链接（很少见但合法），
zip.File.Mode()&os.ModeSymlink != 0，标准库不自动解析，得自己处理Readlink逻辑
并发压缩多个文件，CPU 占用高但吞吐没提升
archive/zip 和 archive/tar 本身不并发，瓶颈在 gzip.Writer 或 zlib.Writer 的压缩计算。开 goroutine 多路写入同一个 zip.Writer 会 panic；而各自开 gzip.Writer 又无法共享字典，压缩率反而下降。
- 别对每个文件起 goroutine 压缩再合流——zip 格式要求文件按顺序写入，强行并发写会破坏结构
- 真正有效的并发点在「读文件」和「压缩」之间：用 goroutine 预读文件到内存 buffer，再串行喂给
zip.Writer - 如果目标是速度优先，换
zstd（用github.com/klauspost/compress/zstd），它原生支持多线程压缩，且 Go 绑定做了 buffer 复用优化
最麻烦的其实是跨平台路径分隔符和权限位——tar 里 Mode 在 Windows 上没意义，zip 里 ExternalAttrs 又和 Unix Mode 映射不一致。这些细节不报错，但解压后行为可能和预期差很远。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
