tar.Writer 默认用0600权限，需显式设header.Mode=fileInfo.Mode().Perm()；符号链接要设Typeflag=TypeSymlink并填Linkname；中文/emoji路径需确保Name是UTF-8且len≤100字节以启用PAX。
tar.Writer 写入时文件权限总是变成 0600？
默认情况下 tar.Writer 不会自动继承源文件的权限，而是用 os.FileMode 的零值（即 0600）填充 header —— 这是新手最常踩的坑。你看到打包后解压出来的文件全是 -rw-------，不是因为磁盘或系统限制，就是没手动设置 Header.Mode。
- 必须显式赋值
header.Mode = fileInfo.Mode().Perm()，注意是.Perm()，不是整个Mode()（后者含 setuid/setgid 等位，tar 不支持） - 如果源文件是符号链接，
fileInfo.Mode()&os.ModeSymlink != 0成立时，应设header.Typeflag = tar.TypeSymlink并填header.Linkname，否则写进去的是空文件 - Windows 下读取的
fileInfo.Mode()可能不含有效权限位，建议在 Linux/macOS 构建环境运行归档逻辑
如何正确处理中文路径或带 emoji 的文件名？
Go 标准库 archive/tar 默认使用 PAX 扩展头（POSIX.1-2001）存文件名，但前提是你的 tar.Header 中 Name 字段是 UTF-8 编码且长度 ≤ 100 字节 —— 超了就自动降级到 GNU 格式，而某些老旧解包工具（如 busybox tar）不认 GNU 扩展，直接报 Invalid tar header。
- 确保输入路径已经是 UTF-8（Go 字符串天然满足），但需检查
len(header.Name) ；超长时用 <code>header.Format = tar.FormatPAX强制启用 PAX - 不要手动修改
header.Name做转义或截断，这会导致解压路径错乱；优先从源头控制文件名长度 - 若目标环境必须兼容老工具（如 Alpine 的 tar），可改用
tar.FormatGNU，但要注意 GNU 格式对非 ASCII 名支持不稳定
打包大量小文件时内存暴涨甚至 OOM？
tar.Writer 本身不缓存文件内容，但如果你用 io.Copy(w, f) 直接写入未缓冲的文件句柄，底层 syscall read/write 的 buffer 大小由 Go runtime 控制（通常 32KB），看似省内存，实则频繁系统调用 + 小块写入会让内核 page cache 压力陡增，尤其在容器里容易触发 cgroup memory limit kill。
- 对每个文件，在
io.Copy前 wrap 一个bufio.Reader，例如buf := bufio.NewReaderSize(f, 64*1024) - 避免把整个文件读进
[]byte再写 —— 即使是 1MB 文件，1000 个也吃掉 1GB 内存 - 如果源是网络流（如 HTTP body），务必加超时和限速，否则 tar 包可能卡在某个
io.Copy里永远不返回
gzip 压缩 tar 包时为什么解压报 “invalid compressed data”？
这不是 archive/tar 的问题，而是压缩层和归档层衔接错误：常见错误是先创建 gzip.Writer，再用它初始化 tar.NewWriter，但没在 tar 写完后调用 gzipWriter.Close() —— 导致 gzip 流尾部 CRC 和 ISIZE 字段缺失，解压器校验失败。
立即学习“go语言免费学习笔记（深入）”；
- 顺序必须是：
gz := gzip.NewWriter(f)→tw := tar.NewWriter(gz)→ 写完所有文件 →tw.Close()→gz.Close() - 漏掉任意一个
Close()都可能导致损坏；用defer容易搞错顺序，建议显式按依赖倒序关闭 - 如果要支持 streaming 解压（如 pipe 到
tar -xzf -），不能用gzip.BestCompression，某些 shell 管道会因压缩块太小而卡住，推荐gzip.DefaultCompression
路径、权限、编码、流控 —— 四个点里漏掉任一环，打包出来的 tar 就可能在某个环境里静默失败。没有“一次写对”的 magic 参数，只有每步都盯着 header 和 close 行为。
