流式打包需用 tar.Writer 直接写入响应或压缩管道，避免磁盘临时文件；关键包括设 tar.FormatPAX 支持中文路径、WriteHeader 勿遗漏、显式缓冲区控制、正确设置 HTTP 头。
用 tar.Writer 边写边压缩，别先生成文件再打包
流式打包的核心是绕过磁盘临时文件，直接把数据写进 tar.Writer，再把它的输出接给 HTTP 响应或压缩管道。常见错误是先用 os.Create 写死一个 .tar 文件，再读它——这既占磁盘又拖慢响应。
关键点：只要底层 io.Writer 支持流式（比如 http.ResponseWriter、gzip.Writer 或 io.PipeWriter），tar.Writer 就能无缝配合。
-
tar.Header.Name必须是相对路径，不能以/开头，否则某些解压工具会拒绝（尤其在浏览器下载时） - 文件内容写入前必须调用
tw.WriteHeader(&header)，漏掉这步会导致归档损坏，但 Go 不报错，只解出来空文件 - 如果要打包目录，得自己递归遍历，
tar包不提供类似archive/tar的“自动打包整个目录”函数
处理中文路径或特殊字符时，tar.FormatPAX 是刚需
默认格式 tar.FormatUSTAR 对文件名长度和字符集限制极严：路径超 100 字节就截断，非 ASCII 字符（如中文、emoji）直接乱码或报错 tar: invalid tar header。
解决方法不是“换库”，而是初始化 tar.Writer 时指定格式：
立即学习“go语言免费学习笔记（深入）”；
tw := tar.NewWriter(outputWriter) tw.Format = tar.FormatPAX // 必须在第一次 WriteHeader 前设
FormatPAX 通过扩展头支持 UTF-8 路径和任意长度名，但代价是归档体积略大（每文件多几十字节头信息），且老系统（如某些嵌入式 busybox）可能不识别。
- 别在循环里反复设
tw.Format，只设一次，且必须早于第一个WriteHeader - 如果目标环境明确是现代 Linux/macOS，
FormatPAX可放心用；若需兼容老旧设备，得提前转 ASCII（比如用 slugify）
避免 io.Copy 直接塞大文件导致内存爆掉
直接 io.Copy(tw, file) 看似简洁，但若源文件是几百 MB 的日志或数据库导出，Go 默认缓冲区（32KB）会让 GC 频繁扫大块内存，实测高并发下 RSS 暴涨。
更稳的做法是控制缓冲区大小，并显式处理中断：
buf := make([]byte, 64*1024) // 显式分配 64KB 缓冲 _, err := io.CopyBuffer(tw, file, buf)
- 缓冲区大小不是越大越好：超过 1MB 后吞吐提升极小，但单次分配压力变大
- 如果源是网络流（如
http.Response.Body），记得检查err是否为io.EOF或连接中断，别让坏包污染整个 tar 流 - 别忘了在
io.CopyBuffer后调用tw.Flush()—— 否则最后一段数据可能卡在缓冲区没写入
HTTP 传输时，Content-Disposition 和 Content-Type 得手动设对
浏览器下载 tar 包时，如果后缀是 .tar.gz 但响应头写成 application/x-tar，Safari 会拒绝自动解压；如果没设 Content-Disposition，文件名常变成随机字符串。
最简够用的头设置：
w.Header().Set("Content-Type", "application/x-tar")
w.Header().Set("Content-Disposition", `attachment; filename="backup.tar"`)
- 如果后端实际输出的是
gzip套tar（即.tar.gz），Content-Type应该是application/gzip，不是application/x-gzip（后者已废弃） - 文件名含中文？用
filename*=UTF-8''xxx.tar格式编码，否则 IE/Edge 会乱码 - 别依赖框架自动推断类型——Gin/echo 默认对
.tar推成application/octet-stream，得手动覆盖
流式打包真正难的不是语法，是边界控制：路径合法性、内存水位、HTTP 头语义、下游解压器的容忍度。每个环节松一点，整条链就容易在生产环境静默失败。
