go处理加密tar.gz需将解密嵌入流管道：gzip.newreader必须直接包装原始加密流，而非解密后reader；aead解密须预读iv、限读密文、单独校验tag；tar层须净化路径防遍历，且各层eof语义必须严格对齐。
Go 处理加密压缩文件（如 tar.gz.enc）时，不能分层“先解密再解压”或“先解压再解密”——必须把解密作为流管道的一环嵌入，否则会破坏 gzip/tar 的字节对齐、header 位置或认证标签完整性。核心难点不在加解密本身，而在流控制与边界协同。
gzip.NewReader 不能套在已解密的 io.Reader 上直接传给 tar.NewReader
常见错误是：用 aes.NewGCM 解密出一个 io.Reader（比如 cipher.StreamReader 或自定义 reader），再把它喂给 gzip.NewReader，最后传给 tar.NewReader。这会导致 tar.Header 解析失败、文件名乱码、权限丢失。
-
gzip.NewReader内部会预读至少 10 字节识别魔数0x1f 0x8b，而 GCM 解密后的流若未对齐（比如开头缺 IV 或 tag 校验失败后残留垃圾），预读就可能落在错误位置 - 更隐蔽的问题是：如果解密流本身不支持
io.Seeker（如 HTTP body、管道），gzip.NewReader预读后无法回退，tar.NewReader拿到的就是偏移错位的流 - 正确做法是：让
gzip.NewReader直接包装原始加密流（如*os.File），然后在它内部做解密 —— 即把解密逻辑下沉到Read方法里，而非在外部拼接 reader 链
AEAD 解密必须在 tar/gzip 流结束前完成校验
用 aes.GCM 加密的文件，末尾固定有 16 字节认证标签（auth tag）。但 tar.NewReader 和 gzip.NewReader 都不感知这个 tag —— 它们只按 header 和 block 处理数据，直到流 EOF 才停止。如果 tag 被当成普通数据喂进去，解压会卡在最后几字节或 panic。
- 解密端必须提前知道 tag 长度（通常是 16 字节），并在读取完整密文后单独截取并验证；不能依赖
io.Copy一路到底 - 推荐结构：
IV(16B) + ciphertext(NB) + tag(16B)。解密时先io.ReadFull读 IV，再用io.LimitReader限制读取N字节密文，最后io.ReadFull读 tag - 切忌把整个文件读进
[]byte再解密——大文件直接 OOM；但也不能跳过 tag 校验直接传给gzip.NewReader，否则篡改无法被发现
路径遍历和空文件头必须在 tar 层拦截，不能靠 zip 或上层逻辑
加密压缩包里的 tar.Header.Name 是攻击面：即使你用了 AES-GCM 防篡改，也无法阻止攻击者在加密前就把 ../../../etc/passwd 写进 tar header。解密+解压后若不做路径净化，照样覆盖系统文件。
- 每次
tr.Next()后立刻检查：filepath.Clean(filepath.FromSlash(h.Name))，再确认结果是否以目标目录绝对路径开头，且不含".."或开头为"/" - 特别注意 Windows：
h.Name可能含"\"或大小写混用，需统一转小写 + 替换分隔符后再比对 - 空
h.Name、h.Typeflag == tar.TypeDir且无结尾"/"、h.Size == 0但非目录 —— 这些都要拒绝，避免创建无效节点或跳过校验
大文件流式处理必须放弃“一次性解密+解压”思维
很多人想用 io.CopyN(dst, decryptReader, h.Size) 解密单个 tar 成员，但这在 AEAD 下不可行：GCM 的 tag 必须在全部密文解密完成后才能验证，而 h.Size 是明文长度，不是密文长度（因填充或 GCM 额外开销），两者不等价。
- 安全做法是：对每个
tar.Header，先计算其密文长度 =h.Size + padding + 16(tag)，再用io.LimitReader(decryptStream, cipherLen)包装，传给gzip.NewReader - gzip 层解压出的流再喂给
io.CopyN(file, gzipReader, h.Size)—— 此时才是真正的明文长度 - 内存控制关键：所有缓冲区（
gzip.Reader内部、io.CopyN默认块）都保持默认 32KB，绝不用make([]byte, h.Size)预分配
最易被忽略的一点：加密压缩流的“EOF”信号来自底层 reader（如 *os.File），但解密层和压缩层各自也有自己的 EOF 语义。三者必须严格对齐，否则 tar.Reader 会误判下一个 header 起始位置 —— 这种错位不会报错，只会静默损坏后续所有文件解析。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
