Go问答：archive/tar PAX长文件名在归档后为什么被截断怎样在批处理代码中减少额外分配

遇到归档后的长文件名像是被截断，先不要急着给路径切片。Go 的 archive/tar 在未指定格式时会选择能容纳当前 Header 的格式；长名称应由 PAX 扩展记录保存。更稳妥的做法是显式设置 tar.FormatPAX，读取时只通过 tar.Reader.Next 获取合并后的 Header.Name，批处理则用流式复制避免把每个文件完整读进内存。

长文件名为什么会看起来被截断

USTAR 的 Name 字段只有有限字节，而 PAX 可以保存更长的名称。Go 文档还说明，PAX 的扩展头使用 TypeXHeader，只作用于紧随其后的文件条目。因此，如果程序直接查看传统文件头中的固定名称栏，或者使用不理解 PAX 的旧查看器，就可能误以为文件名已经丢失；这不代表 Go 的 Header.Name 一定被截断。

中文路径还要区分字节和字符：len(name) 统计 UTF-8 字节数，不能直接当作汉字数量。写入前不要手工截断，也不要把完整路径改成只保留 basename；如果必须兼容只支持 USTAR 的外部工具，应在业务层制定路径映射，而不是破坏归档内的真实名称。

写入时显式选择 PAX

下面的最小写法把长路径和正文分开处理。Header.Size 是正文的字节数，不能填字符数；每个条目写完后再进入下一个头，最后必须检查 Close。

tw := tar.NewWriter(dst)
buf := make([]byte, 32*1024) // 批处理复用缓冲区，避免每个文件重复分配
for _, item := range items {
	hdr := &tar.Header{
		Name:   item.Path,
		Mode:   0600,
		Size:   item.Size,          // 使用正文的字节长度
		Format: tar.FormatPAX,      // 长路径和 UTF-8 名称交给 PAX
	}
	if err := tw.WriteHeader(hdr); err != nil {
		return err // 头写失败时不要继续写正文
	}
	if _, err := io.CopyBuffer(tw, item.Reader, buf); err != nil {
		return err // 流式复制，不把整文件读入 []byte
	}
}
return tw.Close() // 写入补齐块和归档 footer

这里的 item.Size 必须和 Reader 实际提供的字节数一致。写多了会得到 ErrWriteTooLong，写少了则会在下一个 WriteHeader 或 Close 时暴露未完成条目。固定的 32 KiB 只是一个可调起点，不应被文章当成通用最佳值。

读取时验证名称和数据边界

不要自己扫描 tar 的前 100 字节来拼路径，直接用 Reader 的抽象接口：

tr := tar.NewReader(src)
for {
	hdr, err := tr.Next()
	if err == io.EOF {
		break // 所有条目已经读完
	}
	if err != nil {
		return err // 包括格式错误或安全路径错误
	}
	fmt.Printf("%s (%d bytes)\n", hdr.Name, hdr.Size)
	// 当前正文通过 tr 读取；下一次 Next 会丢弃未读完的数据。
	if _, err := io.Copy(io.Discard, tr); err != nil {
		return err
	}
}

排查时可把写入端和读取端都换成 Go 的 archive/tar，再和目标查看器比较。如果 Go 读回名称完整而外部工具显示短名，问题在兼容性；如果 Go 读回也短，检查写入前是否修改了 Name、是否把 rune 数误当成字节数，以及归档是否被中间程序重新打包。

批处理分配与格式边界清单

相关问题

PAX 能否保证所有外部解压工具都保留长路径

不能保证。PAX 是标准化扩展，但极旧或精简的工具可能只读取 USTAR 字段。发布归档前应把目标解压工具纳入回归测试。

为什么不能把 Header.Size 留为零

零表示当前条目没有正文。真实数据仍被写入时会触发写多错误，后续条目的边界也会被破坏。

只想减少分配，是否应该复用 Header 指针

优先复用缓冲区和输入流；Header 的字段会随条目变化，复用时必须完整覆盖字段并清理旧的 PAXRecords，避免状态串到下一项。