archive/tar天然支持流式解析，无需seek；archive/zip依赖中央目录位于文件末尾，要求io.readerat支持随机访问，不可seek的流（如http响应体）必须先缓存再解析。
archive/tar 和 archive/zip 是 Go 标准库中处理压缩流的核心包，但它们对“流式输入”的支持方式完全不同——不是所有压缩格式都天然适合纯流式解析，这点必须提前看清。
Zip 文件无法真正流式解压（除非只读元数据）
archive/zip 要求整个 ZIP 文件可随机访问，因为它的中央目录（central directory）位于文件末尾。这意味着：
• 你不能直接从 io.Reader（比如 HTTP 响应体、管道或未完全写入的文件）安全调用 zip.OpenReader；
• zip.NewReader 确实接受 io.ReaderAt 和长度，但它内部仍需跳转到末尾定位中央目录——所以传入的 reader 必须支持 Seek；
• 如果你拿到的是不可 seek 的流（如 http.Response.Body），必须先完整拷贝到 bytes.Buffer 或临时文件，再构造 zip.Reader；
• 示例错误：直接传 response.Body 给 zip.NewReader 会返回 zip: not a valid zip file 或 panic。
Tar 流天然支持逐块解析
archive/tar 设计上就是流友好的：
• tar.NewReader 只依赖顺序读取，不需要 seek 或预知总长度；
• 可直接包装 gzip.Reader 处理 .tar.gz 流（先解 gzip，再喂给 tar）；
• 每次调用 tr.Next() 返回一个 *tar.Header，之后用 io.Copy 提取内容，内存占用可控；
• 注意：tar header 中的 Size 字段必须可信（恶意归档可能伪造），生产环境建议加限长校验；
• 示例场景：从 S3 getObject 流、Docker image layer 流、或 curl | go run 管道中实时解包。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
如何安全处理未知格式的压缩流？
靠文件扩展名判断格式风险高（比如用户上传 .zip 但实际是 .tar.gz）。更可靠的做法是 sniff 魔数：
• ZIP 开头 4 字节通常是 0x50 0x4b 0x03 0x04；
• TAR 文件开头若为 ASCII “ustar”（offset 257）或 GNU 扩展标识，则大概率是 tar；
• GZIP 流以 0x1f 0x8b 开头；
• 实际代码中，用 io.MultiReader + bytes.NewReader(headerBytes) 把前几百字节“回填”，再根据魔数分发到对应解析器；
• 别忘了：.tar.gz 是两层嵌套流，先 gzip.NewReader，再 tar.NewReader；而 .zip 就是单层，但不支持无 seek 解析。
大文件解压时容易被忽略的资源陷阱
流式处理不等于内存安全：
• tar.NewReader 本身不缓冲，但 io.Copy 默认使用 32KB buffer，对超大单文件（如 >1GB 日志）仍可能触发频繁系统调用；可显式传入自定义 buffer（如 make([]byte, 1）提升吞吐；<br>• ZIP 解压时若未检查 <code>header.UncompressedSize64，恶意归档可能诱导 OOM（zip bomb）；
• 所有 os.Create 路径必须经 filepath.Clean 过滤，否则 ../../../etc/passwd 类路径可导致任意文件覆盖；
• tar.Header.Typeflag 为 '5' 表示目录，'0' 或 '\x00' 表示普通文件——漏判类型会导致 open /path/to/dir: is a directory 错误。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
