Go标准库处理tar.gz需严格遵循三层嵌套顺序（os.File→gzip.NewWriter→tar.NewWriter）及关闭时机（tar.Writer先关、gzip.Writer次之、os.File最后），并强制路径清洗与白名单校验，否则将导致文件损坏或任意写入。
Go 标准库能完整处理 tar.gz，但必须手动组合 archive/tar 和 compress/gzip，漏掉任一嵌套环节或关闭顺序错误，生成的文件就解不开、读不全、甚至被当成损坏包。
压缩目录为 tar.gz：嵌套顺序和关闭时机不能错
核心是三层嵌套：os.File → gzip.NewWriter → tar.NewWriter。不是“先 tar 再 gzip 文件”，而是把 tar.Writer 的输出直接喂给 gzip.Writer。
-
tar.Writer必须在gzip.Writer之前Close()：否则gzip.Writer没法写入尾部 CRC 和 ISIZE，gunzip -t会报unexpected end of file -
gzip.Writer.Close()必须在os.File.Close()之前：否则缓冲区可能未刷盘，文件内容不完整 - 遍历目录请用
filepath.WalkDir（非filepath.Walk），避免符号链接循环导致 panic - 每个
tar.Header必须显式设Typeflag：tar.TypeReg（普通文件）、tar.TypeDir（目录，Name末尾带/），否则 Go 的tar.Reader直接跳过该条目 -
Header.Name必须是相对路径、Unix 风格（/分隔），Windows 路径要先filepath.ToSlash()；绝对路径（以/开头）会被 POSIX tar 拒绝
解压 tar.gz：gzip.NewReader 必须在 tar.NewReader 之前
典型错误是直接对 .tar.gz 文件调用 tar.NewReader(f)，结果立刻报 archive/tar: invalid tar header 或读出空名、零大小——因为 tar.NewReader 只认裸 tar 流，不认识 gzip 压缩头。
- 正确链路：
os.Open→gzip.NewReader→tar.NewReader，缺一不可 - 别在调
gzip.NewReader前对源*os.File做任何Read()或Peek()：gzip.NewReader 内部预读至少 10 字节，提前读会导致 tar header 解析偏移 -
tr.Next()返回*tar.Header后，必须只读header.Size字节：用io.CopyN(dst, tr, header.Size)，而非io.Copy(dst, tr)，否则会吞掉下一个 header - 目录项（
header.Typeflag == tar.TypeDir）的Size是 0，此时跳过CopyN，只调os.MkdirAll(filepath.Dir(name), 0755)
路径安全：clean + 白名单才是防遍历的底线
tar.Reader 对 Header.Name 完全信任，不做过滤。传入 ../../etc/passwd？它真会拼到根目录下写文件。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 先
cleanPath := filepath.Clean(header.Name)，再检查：cleanPath == ""、cleanPath[0] == '/'、strings.HasPrefix(cleanPath, "..")、strings.Contains(cleanPath, "\x00")—— 全部拒绝 - 白名单校验必须用
filepath.HasPrefix(filepath.ToSlash(cleanPath), "expected/subdir/")，目标目录末尾加filepath.Separator（如"./out/"） - 跳过
tar.TypeSymlink和tar.TypeLink条目，防止符号链接逃逸 - 写文件前务必
os.MkdirAll(filepath.Dir(dstPath), 0755)：tar 不保证目录条目一定出现在文件条目前
大文件和错误处理：别让内存或 panic 拖垮服务
直接 io.Copy(tw, f) 处理几百 MB 文件，极易 OOM；忽略 gzip.Writer.Close() 返回的 error，则损坏文件无声无息。
- 大文件写入不要一次性
ReadAll或io.Copy：用固定 buffer（如 32KB）循环Read/Write，控制内存峰值 -
gzip.Writer.Close()可能返回io.WriteShort或压缩层错误，必须检查，不能只defer - 解压时若
header.Size 或为 0（某些老旧打包工具行为），别硬套 <code>io.CopyN：改用io.Copy(dst, io.LimitReader(tr, maxBytes))加上限 - 写入前校验路径安全性，解压后验证文件权限/时间戳是否合理——这些都不是标准库管的事，是你代码的责任
最易被忽略的其实是关闭顺序和路径校验：前者让文件看似生成成功实则无法解压，后者让服务端压缩功能变成任意文件写入入口。这两点不卡死，其他都白搭。
