gzip.NewReader 返回值不可直接传给 tar.NewReader，因其预读破坏 tar header 起始位置；须确保源 io.Reader 可重放，且未被提前消费。
gzip.NewReader 不能直接传给 tar.NewReader？
对，tar.NewReader 要的是 io.Reader，但你如果把 gzip.NewReader 的返回值直接塞进去，解出来的文件名、权限全乱——因为 gzip.NewReader 返回的是一个带缓冲的 reader，它内部会预读一部分数据来判断 gzip header，而 tar.NewReader 从头开始解析 tar header 时，已经错过了真正的起始位置。
正确做法是：先用 gzip.NewReader 解包，再把它的 Reader 字段（即原始未缓冲的底层 reader）交给 tar.NewReader ——但等等，gzip.Reader 没有公开的 Reader 字段。所以实际必须用 gzip.Reader 自身作为 tar.NewReader 的输入，但要确保它没被提前消费过。
- 确保传入
gzip.NewReader的原始io.Reader是可重放的（比如bytes.Reader或文件*os.File），否则流式场景下一旦 gzip 预读失败就不可恢复 - 别在调用
gzip.NewReader前对源 reader 做任何Read或Peek操作 - 如果源是 HTTP body 这类一次性流，必须用
io.TeeReader或临时 buffer 记录前几个字节做 magic check，再决定是否走 gzip 分支
tar.Header 中的 Name 字段含路径遍历风险？
是的，tar.Header.Name 可能是 ../../etc/passwd 这种，直接拼到 os.OpenFile 路径里等于开后门。Go 标准库不自动 sanitize，得你自己拦。
关键不是“过滤点点斜杠”，而是用 filepath.Clean + filepath.HasPrefix 做白名单校验：
立即学习“go语言免费学习笔记（深入）”；
- 先用
filepath.Clean(header.Name)归一化路径，消除./、../等干扰 - 再检查结果是否以你预期的解压根目录（比如
"tmp"）开头，且不含".."片段 - 特别注意 Windows 路径分隔符：
filepath.FromSlash统一转成本地格式再校验，避免"..\foo"绕过 - 空名、以
/开头、含\0的Name都该直接跳过或报错
流式解压时如何避免内存暴涨？
常见错误是把整个 tar.Header.Size 读进 []byte 再写文件——万一遇到 2GB 的单个文件，Go runtime 就直接 OOM 了。流式核心就是“边读边写”，不缓存全文。
- 用
io.CopyN(dst, tr, header.Size)替代循环Read，它内部按 32KB 分块，可控且高效 - 对每个
header，打开目标文件后立刻设defer f.Close()，别等整个 tar 流结束才关 - 如果要限速或监控进度，套一层
io.LimitReader或自定义io.Reader实现Read计数，别碰Size字段做预分配 - 注意
tar.Reader的Next()会隐式跳过 padding，但如果你手动Read数据，得自己对齐 512 字节块，否则后续Next()错位
gzip: invalid checksum 错误常出现在哪几个环节？
这个错误不是 tar 层面的，是 gzip.NewReader 在 EOF 时校验 trailer 失败。流式场景下最常因为：提前关闭了底层 reader，或者 HTTP body 被多次读取。
- 确认源 reader 没被其他 goroutine 并发读，gzip 校验需要完整流到底
- 如果用了
http.Response.Body，别在gzip.NewReader之前调用resp.Body.Close()，也别用io.MultiReader拼接多个 body - 测试时用
bytes.NewReader(data)替代真实流，能快速定位是不是数据截断 - 某些代理或 CDN 会偷偷 chunk-encode 或改 content-encoding，抓包看响应 header 的
Content-Encoding: gzip是否真实存在且未被篡改
流式解压真正难的不是代码几行，是每层 reader 的生命周期和边界谁负责清理、谁可能提前 EOF、谁悄悄改了数据——这些地方一松动，错误就藏在 gzip 校验或 tar header 解析的缝隙里，很难复现。
