文件内容为空是因为仅创建FileHeader而未调用io.Copy写入数据；必须显式读取源文件并写入，且需设置Method、调用zw.Close()，解压时须用filepath.Clean校验路径防遍历漏洞。
archive/zip 创建压缩包时为什么文件内容为空？
直接用 zip.FileHeader 构造文件头但没写入数据，是空文件的最常见原因。Go 的 archive/zip 不自动读取磁盘文件，必须显式调用 io.Copy 或手动写入。
- 错误做法：
zw.CreateHeader(&zip.FileHeader{Name: "a.txt"})后不写内容 - 正确流程：先
zw.CreateHeader()，再从源文件os.Open并io.Copy(Writer, Reader) - 注意
FileHeader.Method默认为 0（未压缩），设为zip.Deflate才真正压缩 - 别漏掉
zw.Close()，否则末尾目录区写不全，解压会报“invalid zip header”
如何递归压缩整个目录（含子目录）？
archive/zip 本身不提供遍历能力，得靠 filepath.WalkDir（Go 1.16+）或 filepath.Walk 配合手动处理路径。
- 遍历时用
entry.IsDir()跳过目录本身（ZIP 中目录靠文件名结尾的/标识） - 文件路径需转为 ZIP 内部路径：用
strings.TrimPrefix(path, rootDir)去掉前缀，再把\替换为/ - 对每个文件创建
zip.FileHeader时，记得设置ModTime和Method，否则部分解压工具可能报时间异常或不解压 - 示例关键片段：
header, _ := zip.FileHeaderFromFileInfo(name, fi) header.Name = zipPath // 如 "sub/a.txt" header.Method = zip.Deflate w, _ := zw.CreateHeader(header) io.Copy(w, f)
解压时怎么避免路径遍历漏洞（如 ../../etc/passwd）？
直接用 zr.Open() 得到的 zip.File 的 Name 是用户可控的，不做校验会导致任意文件写入。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须对每个
f.Name调用filepath.Clean(f.Name)，再检查是否以目标解压目录开头 - 禁止出现
..、/开头、空名称，例如：cleaned := filepath.Clean(f.Name) if strings.HasPrefix(cleaned, "..") || strings.HasPrefix(cleaned, "/") || cleaned == "" { return fmt.Errorf("unsafe file path: %s", f.Name) } - 写入前确保目标路径在解压根目录内：
dst := filepath.Join(destDir, cleaned)，再用os.Stat(dst)检查父目录是否仍是destDir - Windows 下还要额外处理
:$DATA等 NTFS 流后缀（虽罕见，但安全场景不能忽略）
gzip 和 zip 混淆导致解压失败？
新手常把 compress/gzip 和 archive/zip 当成同一类——前者只压缩单个流（类似 .gz），后者是容器格式（可含多文件+目录结构）。
立即学习“go语言免费学习笔记（深入）”；
- 用
compress/gzip压缩的文件，不能用archive/zip打开；反之亦然 - 错误现象：
zip: not a valid zip file或gzip: invalid header - 确认文件类型：Linux 下用
file xxx.zip，看输出是否含 “Zip archive data” - 如果只是想压缩单个文件且追求简单，用
compress/gzip更轻量；需要多文件/目录结构，必须用archive/zip
路径处理和校验逻辑最容易被跳过，尤其是解压时的 filepath.Clean 和前缀检查——线上环境一旦出问题，就是任意文件写入漏洞。压缩时的 Method 和 Close 也常被忽略，导致生成的 ZIP 在某些老旧解压器里打不开。
