Go archive/tar 解包稀疏文件为什么占用空间变大

用 Go 的 archive/tar 解包一个看起来只有几百 MB、但逻辑长度达到几十 GB 的稀疏文件时，解包目录可能很快吃满磁盘。原因通常不是 tar.Reader 重复读取，而是稀疏文件里的“空洞”在读取接口中会表现为 NUL 字节；直接 io.Copy 到普通文件，就会把这些零字节真实写入磁盘。先分清逻辑大小和实际块占用，再决定是否需要保留稀疏属性。

先确认“变大”指逻辑长度还是磁盘占用

你用Go标准库的`archive/tar`解压稀疏文件时，最终得到的文件占用磁盘空间会远大于原稀疏文件的实际逻辑大小，核心原因是标准库默认没有实现稀疏孔洞的识别与还原逻辑，会把文件所有偏移位置的内容（包括原本全零的孔洞段）全部以实际写入的方式落盘，自然就把所有空洞都占满了。

Go原生`archive/tar`在解压普通tar包时，不会主动调用系统 punching hole 相关的能力，所有从tar流里读到的内容都会直接连续写入目标文件，哪怕对应段全是零值，最终生成的文件也会占用完整的逻辑大小磁盘空间，失去原稀疏文件的空间节省特性。

稀疏文件可以有很大的逻辑范围，但中间连续的零区域不分配实际磁盘块。archive/tar 的 Header.Size 描述的是逻辑文件大小；它用于告诉读取器当前条目应该读到哪里，不代表已经写入了同样多的磁盘块。解包前后同时记录逻辑大小和文件系统块数，才能判断是预期的空洞物化还是异常重复写入。

观察项	代表什么	排查意义
Header.Size	逻辑文件长度	决定 Reader 的读取边界
Header.Typeflag	条目类型，GNU 稀疏文件常见为 TypeGNUSparse	提示需要检查稀疏元数据
PAX GNU.sparse.*	稀疏文件的大小和数据区映射	可用于实现保留空洞的写入策略
文件系统块数	实际分配的空间	与逻辑大小对比空间膨胀

从 Header 和 PAXRecords 识别稀疏条目

Go 官方 archive/tar 同时覆盖 USTAR、PAX 和 GNU 变体。PAX 稀疏格式通常把 GNU.sparse.size、GNU.sparse.map 等记录放进 Header.PAXRecords；旧式 GNU 稀疏条目则可能通过 TypeGNUSparse 表示。不要只依据扩展名或归档文件名判断。

func inspectEntry(tr *tar.Reader) error {
	// Next 返回一个条目的头；Reader 会在内部处理 PAX 扩展头。
	hdr, err := tr.Next()
	if err != nil {
		return err // io.EOF 表示归档结束，其他错误需要停止当前条目
	}

	if hdr.Typeflag == tar.TypeGNUSparse {
		fmt.Println("GNU sparse entry:", hdr.Name) // 旧式 GNU 稀疏标记
	}
	if size := hdr.PAXRecords["GNU.sparse.size"]; size != "" {
		fmt.Println("logical sparse size:", size) // PAX 记录中的逻辑大小
	}
	if sparseMap := hdr.PAXRecords["GNU.sparse.map"]; sparseMap != "" {
		fmt.Println("sparse map present") // 映射描述数据区，不能当普通正文处理
	}

	return nil // 当前条目的正文仍需通过 tr 读取或跳过
}

这里的检测只负责建立决策依据，不等于已经完成稀疏还原。尤其是 PAX 映射可能分成不同版本的键，生产代码应校验偏移量、长度是否越界，并确认映射覆盖范围不超过逻辑大小。

为什么 io.Copy 会让空洞真正占空间

tar.Reader 对稀疏区的公开读取语义是返回 NUL 字节。下面这种代码很稳定，也很容易理解，但它的结果是“还原完整字节流”，而不是“保留文件空洞”：文件系统会为连续写入的零字节分配实际块。

func extractLogical(dst *os.File, tr *tar.Reader) error {
	// 这种路径优先保证跨平台的字节内容一致，不承诺保留稀疏布局。
	if _, err := io.Copy(dst, tr); err != nil {
		return fmt.Errorf("copy tar entry: %w", err) // 写满磁盘等错误必须向上返回
	}
	return nil // 逻辑内容已写入，实际占用可能接近 Header.Size
}

因此，空间变大本身并不能证明内容错误。它只说明接收端把“洞”当成了普通零字节。若归档来自不可信来源，还要在创建目标文件前限制 Header.Size，避免一个很小的压缩归档展开成超大逻辑文件。

必须保留稀疏属性时怎么选方案

如果目标是跨平台恢复内容，继续使用顺序写入最简单；如果目标是节省磁盘，必须使用稀疏映射重建文件：先按映射定位真实数据区，写入每个数据区前用 Seek 跳过空洞，最后用 Truncate 设置逻辑长度。不能仅凭“读到一段全零”就推断它是空洞，因为真实数据也可能是零字节。

在 Go 标准库公开 API 的边界内，PAX 的 GNU.sparse.* 记录可以作为解析输入；旧式 GNU 稀疏格式的底层映射处理更依赖库内部细节。若必须兼容多种 GNU/PAX 变体和不同操作系统，优先交给目标平台上明确支持 sparse restore 的归档工具，Go 程序负责路径、权限和资源限制。

目标	推荐处理	代价
只需恢复字节内容	io.Copy 顺序写入	可能把空洞物化，占用接近逻辑大小
需要节省本地空间	解析映射，Seek 写真实区间并 Truncate	格式解析、平台语义和异常恢复更复杂
需要广泛兼容 GNU/PAX	调用经过验证的稀疏归档工具	增加外部依赖和进程治理工作

常见问题

为什么 ls -l 和磁盘剩余空间看起来对不上？

ls -l 更接近逻辑长度，而磁盘剩余空间反映实际分配块；稀疏文件正是利用了两者之间的差异。

把零字节跳过写入就能保留稀疏文件吗？

不能可靠保证。真实数据也可能是零字节，只有归档携带的稀疏映射才能区分“洞”和“真实零数据”。

设置 Header.Size 小一点能减少占用吗？

不能。它是归档条目的逻辑边界，擅自改小会截断内容；应在写入前设置展开大小上限，而不是修改合法的大小字段。

排查 Go 解包稀疏文件时，先记录 Header.Size、条目类型和 PAX 映射，再确认写入路径是否使用了 io.Copy。接受内容物化时把展开上限做好；必须节省空间时，围绕映射实现或选用真正支持稀疏恢复的工具。