1. 先把问题拆开：为什么压缩解压值得单独做一层封装

压缩和解压这件事，看上去是命令行里最没有技术含量的操作之一。tar -zxf敲了十年，unzip闭着眼都能打出来。但只要你在团队里待过一段时间，就一定遇到过这样的场面：新人拿到一个.tar.zst文件，先装 zstd，再查 tar 支不支持--zstd，最后发现系统自带的 tar 版本太老，绕了二十分钟才解开一个本该三十秒搞定的事。zuz 这类模块存在的意义，就是把这段来回试错的路给抹平——它不去重新实现压缩算法，而是做一个统一的入口层，让你用同一套命令、同一套参数习惯，处理 tar.gz、tar.xz、tar.zst、zip、7z、rar、单个 gz 或 xz 文件，甚至后缀名写错的文件。

我最初接触这套东西的动机很朴素：一台机器上同时装着 GNU tar、bsdtar、p7zip 和 unzip，每个工具的参数命名风格都不一样。tar用-z -j -J，zip用-r -9，7z用-mx=9，rar又是另一套。写脚本的时候最烦的不是逻辑，是这些方言切换。后来我把这些调用全收拢到一个固定的入口后面，脚本里只出现一种写法，剩下的交给封装层去判断该调谁。zuz 这个模块的思路基本一致，只不过它做成了工具箱里的一个子命令，顺带把"文件是什么格式""这台机器有没有对应的工具""要不要自动补依赖"这几件事都包了进去。

适合读这篇的人分两类。一类是经常写构建脚本、部署脚本、备份脚本的，你需要的是一套稳定可复用的调用约定，而不是每次现查 man 手册；另一类是被压缩包格式折腾过的普通用户，你只需要知道"我把文件扔给它，它自己认得出来"就够了。中间那些原理和坑，我会尽量讲透，让你在封装层失灵的时候知道往哪儿看。

1.1 命令行压缩的真实痛点不在"压缩"本身

真正让人头疼的是三件事：格式判定、工具缺失、参数方言。格式判定听起来简单，看后缀不就完了？实际不是。有人把 zip 改名成.tar.gz，有人下载的文件后缀是.tar.gz但内容其实是裸 gzip 流，还有.tgz、.tbz2、.txz、.zst、.tar.zst这些省略写法混在一起。靠后缀猜，出错概率相当高。

工具缺失是第二个坑。压缩算法是分层的，tar 只是打包，真正的压缩靠 gzip、bzip2、xz、zstd 这些外部程序。一台精简安装的服务器上，xz 和 zstd 大概率没有；某些容器镜像里连 bzip2 都省了。你写一个tar -cJf上去，报错信息是tar: xz: Cannot exec: No such file or directory，对不熟悉的人就是一脸问号——明明用的是 tar，怎么在说 xz 找不到。

参数方言是第三个。同一个"最高压缩级别"，gzip 是-9，xz 是-9e，zstd 是-19甚至-22，7z 是-mx=9。同一个"输出到指定文件"，tar 是-f，zip 是位置参数，7z 也是位置参数但顺序讲究。这些差异本身不难，难在你要在脚本里记住十几套组合，还得考虑跨平台。

一个常见误区：很多人以为"压缩级别越高越好"。实际上从-6到-9，文件体积往往只缩小 3% 到 8%，耗时却可能翻两到三倍。备份场景里，这个交换比通常不划算。

1.2 zuz 这类模块的设计取舍

把这层封装做出来，第一件事是决定"封到什么程度"。有三种典型路线。第一种是纯别名，把常用参数固定下来，本质上还是调原生命令，好处是零学习成本，坏处是格式判断、依赖处理这些真正麻烦的事一样没解决。第二种是全自研，自己实现格式解析和调用逻辑，甚至内嵌压缩库，好处是可控，坏处是维护成本极高，新格式一出来就得跟着改。第三种是中间路线：保留外部工具做实际工作，自己只负责"识别 + 路由 + 参数翻译 + 错误提示"。

zuz 走的是第三条。这个取舍的道理很实在——压缩算法本身是成熟且高度优化的，重新实现一遍既没必要也不安全，真正的价值在调度层。调度层的核心工作有四项：认清输入是什么、确认机器上有什么、把统一参数翻译成目标工具认识的写法、把错误信息翻译成人能看懂的话。这四件事加起来，就是使用体验的全部差异。

这种设计的另一个好处是可降级。当机器上缺 zstd 时，封装层可以明确告诉你"这个文件需要 zstd，是否安装或者改用其他方式"，而不是把一条来自底层进程的、夹杂着路径和 errno 的报错直接甩给你。对写脚本的人来说，可预期的报错比快速失败更有价值——你可以在脚本里判断返回码和错误类型，做不同分支处理。

代价也要说清楚。封装层多了一层进程调用，开销虽然可以忽略（相对于压缩本身），但调试链路变长了。出问题的时候你要分清是封装层判断错了格式，还是底层工具执行失败。所以我一般建议：封装层用来做日常和高频操作，遇到疑难杂症时先用file和原生工具验证一遍，确认问题出在哪一层。

1.3 封装层与原生命令的能力对照

我把两者的差异整理成一张表，方便你判断什么场景该用哪边。表里的判断基于我自己的使用习惯，不是绝对标准。

结论很清楚：日常解压、批量归档、写给别人用的脚本，用封装层；需要压榨最后一点压缩率、或者要做特殊的分卷与加密组合，直接上原生工具。两者不是替代关系，是分工关系。

2. 核心机制拆解：格式识别、依赖调度与参数映射

这一节讲的是封装层内部最关键的几个判断逻辑。你不需要照着实现一遍，但理解它怎么想问题，出问题时能少走很多弯路。

2.1 后缀名只是线索，文件头才是证据

文件格式判定的第一原则：先看文件头（魔数），再看后缀。原因很简单，后缀是人起的，文件头是程序写的。常见的魔数我列一下，这些值你在排查问题时用xxd file | head -n 1就能看到。

要注意最后一行，tar 的魔数不在文件开头，而在第 257 字节偏移处。这就是为什么判断 tar 需要多读一段。很多判定逻辑会先读前 512 字节，看完开头再跳到偏移位置确认 ustar 标记，两者都对上才认定是 tar 包。

实际判定顺序我建议这样排：先读文件头，命中已知魔数就直接用；没命中再看后缀；后缀也没有就尝试file命令兜底；全都失败就明确告诉用户"无法识别，请确认文件是否完整"。这个顺序能覆盖绝大多数情况，包括那种把 zip 改名成.tar.gz的恶作剧文件。

有个细节容易忽略：一个文件可能同时是"tar 包 + gzip 压缩"，也就是外层 gzip、内层 tar。判定逻辑要能识别这种嵌套关系，先解外层压缩，再处理内层打包。这就是tar.gz必须用tar -zxf而不能只gunzip的原因——后者只会给你一个 tar 裸包。

2.2 依赖探测与优雅降级

判定出格式之后，下一步是确认工具在不在。这一步看起来简单，实际决定了整个封装层的健壮程度。最直接的做法是command -v检查，但要注意几个坑。

第一个坑是同一工具的多个变体。tar有 GNU tar 和 bsdtar 两个大流派，bsdtar 内置了对 zstd 的支持，GNU tar 老版本需要借助-I zstd或者--zstd。zip有 Info-ZIP 版本，也有某些系统上阉割过的版本，后者可能不支持-s分卷。探测的时候要连版本一起看，不能只判断"存在"。

第二个坑是"存在但不可用"。比如7z命令存在，但它只是一个包装脚本，实际依赖的7za没有装。这种情况command -v会通过，真正执行时才失败。稳妥的做法是做一次极轻量的冒烟测试，比如调用它的版本输出，返回码为零才算可用，把结果缓存起来避免重复检查。

第三个坑是降级策略的选择。当目标工具缺失时，有三条路可走：报错退出、尝试等价方案、提示安装。我倾向这样分级——如果存在语义等价的替代（比如要 zstd 但没有，而用户只是要"压缩一下"，可以退回 gzip 并明确告知），就降级并输出提示；如果不存在等价替代（比如要解 rar，没有 unrar 就是没辙），就干脆报错，把需要装什么写清楚。绝不要静默降级，那会让用户以为拿到了 zstd 包，实际是 gz，后续流程全乱。

2.3 参数映射表：把"压缩级别"翻译成各家的方言

统一入口最大的价值就在这里。用户只想表达"压得狠一点"或者"快一点"，封装层负责翻译。

这张表里最容易出错的是 zstd。它的级别区间是 1 到 22，默认 3，而 19 以上属于"极限模式"，速度掉得很厉害。很多人习惯性给 zstd 加-19，结果压缩一个 2GB 的包花了十几分钟，比 xz 还慢，完全失去选 zstd 的意义。我的经验是：日常归档用-3到-6，长期冷备才考虑-15以上。

xz 的-9e也要单独说。e是 extreme 模式，在-9基础上进一步增大字典和搜索深度，压缩率提升有限但内存占用和耗时明显上升。压缩大文件时-9e可能吃掉几个 GB 内存，在内存吃紧的机器上会直接被 OOM 杀掉。给个量级参考：压缩 1GB 的文本类数据，gzip-6大概几十秒，zstd-3十几秒，xz-6几分钟，xz-9e可能十几分钟。这些数字随数据特性浮动很大，但相对关系基本稳定。

还有一个隐藏参数是"线程数"。zstd 和 xz 都支持多线程（-T0用满所有核），gzip 基本单线程。在多用核机器上，zstd 加-T0的吞吐能翻好几倍。封装层如果暴露了线程参数，值得优先用它，而不是一味调级别。

2.4 解压路径的安全边界

这一点经常被忽略，但在服务端场景里极其重要。恶意构造的压缩包可以在条目名里塞../../etc/xxx这样的相对路径，解压时就会写到目标目录之外，业内叫路径穿越。封装层应该在解压前或解压过程中做校验。

校验逻辑不复杂：解压前先列出所有条目名，逐个检查。凡是包含..路径段的、以/开头的绝对路径、包含盘符的（Windows 风格）、或者解析后的真实路径不在目标目录之下的，一律拒绝并明确报告是哪个条目出的问题。实施上，很多原生工具已经带了这个保护，但版本差异大，不能全指望。

我在实际项目里的做法是：默认开启校验，对于确认可信的内部包提供一个显式开关跳过。宁可多一步确认，也不要让一个来源不明的包在服务器上随意落盘。

3. 动手复刻：一套能直接抄走的实现

前面讲的都是判断逻辑，这一节给能跑的东西。我用 shell 实现一版精简的，功能覆盖日常九成场景，你可以直接拿去改。

3.1 目录结构与入口约定

我习惯把这类工具做成单文件加一个可选的配置文件。单文件的好处是拷贝方便，扔到任何有 bash 的机器上都能用。

# 目录约定 ~/bin/zuz # 主入口脚本 ~/.config/zuz/conf # 可选配置：默认压缩级别、临时目录等

入口脚本的骨架大致这样：

#!/usr/bin/env bash set -euo pipefail VERSION="1.0" # 统一日志输出函数，所有提示走这里，方便以后加静默模式 log() { printf '[zuz] %s\n' "$*" >&2; } die() { printf '[zuz] 错误: %s\n' "$*" >&2; exit 1; } need() { command -v "$1" >/dev/null 2>&1 || die "缺少依赖工具: $1"; }

set -euo pipefail这三件套是必须的。-e让任何命令失败立即退出，-u让引用未定义变量报错，pipefail让管道中任一环节失败都能被捕获。少任何一个，脚本都可能在错误状态下继续跑，产生半截文件。

3.2 解压路由：按格式分发

解压是最高频的操作，先实现它。核心是先探测格式，再分发。

detect_format() { local f="$1" local head head=$(head -c 512 "$f" 2>/dev/null | od -An -tx1 | tr -d ' \n') case "$head" in 1f8b08*) echo "gz" ;; 425a68*) echo "bz2" ;; fd377a585a00*) echo "xz" ;; 28b52ffd*) echo "zst" ;; 504b0304*) echo "zip" ;; 377abcaf271c*) echo "7z" ;; 52617221*) echo "rar" ;; *) echo "unknown" ;; esac }

这段只覆盖单层压缩和 zip 系列。tar 的判定要补一刀：

is_tar() { # tar 的 ustar 标记在偏移 257 字节处 local magic magic=$(dd if="$1" bs=1 skip=257 count=5 2>/dev/null) [ "$magic" = "ustar" ] }

两个合起来的判定流程是：先确认是不是 tar，是的话再看它外层还有没有压缩——这一步可以直接交给tar自己做，GNU tar 的-xf在较新版本里能自动识别压缩算法。所以解压 tar 系列我建议一条命令通吃：

extract_tar() { local f="$1"; local dest="${2:-.}" mkdir -p "$dest" tar -xf "$f" -C "$dest" --no-same-owner }

--no-same-owner是给非 root 用户准备的。不加这个参数，解压别人的包时 tar 会试图还原原始 uid/gid，普通用户没权限，直接报错退出。这个坑我踩过不止一次，加上就清净了。

分发函数：

extract() { local f="$1"; local dest="${2:-.}" [ -f "$f" ] || die "文件不存在: $f" mkdir -p "$dest" local fmt if is_tar "$f" || tar -tf "$f" >/dev/null 2>&1; then fmt="tar" else fmt=$(detect_format "$f") fi log "识别为 $fmt，解压到 $dest" case "$fmt" in tar) extract_tar "$f" "$dest" ;; zip) need unzip; unzip -q -o "$f" -d "$dest" ;; 7z) need 7z; 7z x -o"$dest" -y "$f" >/dev/null ;; rar) need unrar; unrar x -o+ "$f" "$dest"/ >/dev/null ;; gz) need gzip; gzip -dc "$f" > "$dest/$(basename "${f%.gz}")" ;; bz2) need bzip2; bzip2 -dc "$f" > "$dest/$(basename "${f%.bz2}")" ;; xz) need xz; xz -dc "$f" > "$dest/$(basename "${f%.xz}")" ;; zst) need zstd; zstd -dc "$f" > "$dest/$(basename "${f%.zst}")" ;; *) die "无法识别格式: $f" ;; esac }

注意tar -tf "$f"这一句既做判定又做完整性初检。如果这个包是坏的，这里就会失败，比解压到一半再崩要好。代价是对超大包多读一遍，几 GB 以内完全可接受。

3.3 压缩路由与默认参数怎么定

压缩这边要先定一件事：输出文件名怎么来。我的规则是"源目录名 + 格式后缀"，比如zuz c logs默认产出logs.tar.gz，格式可以通过第二参数指定。

compress() { local src="$1" local fmt="${2:-tar.gz}" local level="${3:-default}" local out="${src%/}.${fmt}" [ -e "$src" ] || die "路径不存在: $src" case "$fmt" in tar.gz) need gzip local lv="-6"; [ "$level" = "fast" ] && lv="-1"; [ "$level" = "max" ] && lv="-9" tar -cf - "$src" | gzip "$lv" > "$out" ;; tar.zst) need zstd local lv="-3"; [ "$level" = "fast" ] && lv="-1"; [ "$level" = "max" ] && lv="-19" tar -cf - "$src" | zstd -T0 "$lv" -q -o "$out" ;; tar.xz) need xz local lv="-6"; [ "$level" = "fast" ] && lv="-0"; [ "$level" = "max" ] && lv="-9e" tar -cf - "$src" | xz -T0 "$lv" > "$out" ;; zip) need zip local lv="-6"; [ "$level" = "fast" ] && lv="-1"; [ "$level" = "max" ] && lv="-9" zip -q -r -y "$lv" "$out" "$src" ;; *) die "不支持的输出格式: $fmt" ;; esac log "已生成 $out" }

这里有个细节值得单独讲：tar -cf - "$src" | gzip > "$out"这种管道写法，比tar -czf好在哪？好在可控。中间这一层你可以插pv看进度，插tee做双份，或者在出错时更容易判断是打包阶段失败还是压缩阶段失败。tar -czf把两件事揉在一起，出问题时信息更少。

另一个细节是zip -y。这个参数让 zip 把符号链接存成链接本身，而不是跟随链接把目标文件内容打进去。不加这个参数，一个指向大文件的软链接会让包体莫名其妙变大，解压后链接也变成了普通文件。做代码打包时这个区别很关键。

3.4 分卷、密码与批量处理

大文件传输经常需要切分。zip 和 7z 都支持原生分卷，tar 系列要靠split补。

# zip 分卷，每卷 100MB zip -q -r -s 100m -y out.zip dir/ # 7z 分卷 7z a -v100m out.7z dir/ >/dev/null # tar 流式分卷：先压再切 tar -cf - dir/ | zstd -3 | split -b 100m - "backup.tar.zst.part." # 还原时按顺序拼回去 cat backup.tar.zst.part.* | zstd -dc | tar -xf - -C ./restore

分卷的坑在还原。split产生的分片名字是排好序的，cat时用通配符展开一般没问题，但如果分片超过 10 个，part.10会排在part.2前面吗？只要命名时用了固定位宽的补零（part.000、part.001），自然顺序就正确。不补零的话就老老实实按数字排序拼。这个我吃过亏，拼出来的包解压报unexpected end of file，查了半天才发现是顺序错了。

加密这块，zip 的老式加密（-P参数）安全性很弱，能不用就不用。要加密优先选 7z 的 AES-256：

7z a -p -mhe=on secure.7z dir/

-mhe=on是加密文件名，不加的话文件名列表是明文的，别人能看到你包里有哪些文件，即使打不开。需要真正保密时这个开关必开。

批量处理用一层循环就够了，重点是要做失败统计，不能让一个坏文件中断整批：

for f in *.zip; do extract "$f" "out/${f%.zip}" || log "跳过失败项: $f" done

|| log这个写法配合前面set -e会有点微妙——因为||会吞掉非零返回码，所以循环不会中断。这正是批量场景想要的行为。

3.5 挂到 PATH 上并配好别名

脚本写完后给执行权限，扔到 PATH 里的某个目录：

chmod +x ~/bin/zuz echo 'export PATH="$HOME/bin:$PATH"' >> ~/.bashrc

如果想把默认压缩格式固定成 zstd（我一般这么干，速度优势明显），可以在配置里加一个变量，脚本里fmt="${2:-${ZUZ_DEFAULT_FMT:-tar.gz}}"，然后在~/.bashrc里export ZUZ_DEFAULT_FMT=tar.zst。这种"默认值可从环境变量覆盖"的写法，比硬编码要灵活得多，团队里每个人可以按自己的习惯配。

4. 高频故障排查实录

这一节是我这些年攒下来的问题清单，按出现频率排。很多问题看起来吓人，实际上有固定解法。

4.1 三个最常撞上的报错

第一个：tar: xz: Cannot exec: No such file or directory

字面意思是找不到 xz 程序，但你明明在敲 tar。原因就是前面说的分层结构——tar 只是调度，实际压缩靠外部程序。解决就是装对应工具。判断需要装哪个，看报错里点名的程序名：说 xz 就装 xz，说 zstd 就装 zstd，说 bzip2 就装 bzip2。装完重跑即可，不需要重打 tar 包，因为失败的只是压缩那一步。

顺带说一个变体：报错是tar (child): zstd: Cannot exec，这个(child)是 GNU tar 在告诉你"我的子进程出问题了"，跟上面是同一回事。

第二个：gzip: stdin: unexpected end of file

这个通常意味着压缩包不完整。常见于下载中断、磁盘写满、或者分卷拼接顺序错了。排查顺序是：先比对文件大小和源站给的校验值，再确认磁盘剩余空间，最后检查分卷拼接。unexpected end of file有时候也出现在文件本身没问题、但被管道截断的情况——比如curl ... | tar -xz中途网络断了。

一个容易误判的场景：某些环境下set -o pipefail已开启，管道前半段的 tar 正常结束，后半段因为磁盘满失败，报错会指向 tar。这时候去看磁盘，df -h一眼就明白了。

第三个：解压后中文文件名全是乱码

这是 Windows 和 Linux 之间交换 zip 的经典问题。Windows 上打的 zip 多数用 GBK 编码存文件名，Linux 的 unzip 默认按 UTF-8 解释，结果就是一堆问号方块。处理链有三步。

先确认是不是编码问题：unzip -l file.zip看列表里的名字。如果显示乱码，基本可以确定。然后尝试指定编码解压：

# Info-ZIP 较新版本支持 -O unzip -O CP936 file.zip -d out/ # 不支持 -O 的版本，用 7z 更稳 7z x -mcp=936 file.zip -oout/ # 终极方案：用 Python 自己控制 python3 -c " import zipfile, sys z = zipfile.ZipFile(sys.argv[1]) for i in z.infolist(): name = i.filename.encode('cp437').decode('gbk', 'replace') z.extract(i, 'out') import os os.rename(os.path.join('out', i.filename), os.path.join('out', name)) " file.zip

第三段 Python 逻辑是：zipfile 默认把非 UTF-8 标记的文件名按 cp437 解码，得到一串错误的字符，把它按 cp437 重新编码回字节、再按 gbk 解码，就还原了原文件名。这个方法我在处理历史遗留包时用过很多次，成功率很高。反过来如果是 Linux 打包传到 Windows 乱码，逻辑对称，把 gbk 换成 utf-8 即可。

4.2 其他常见问题的处理要点

权限丢失。tar 默认保留权限位，zip 不加参数会丢掉执行权限。如果你打包的是可执行文件，解压后发现Permission denied，用chmod +x补回来，或者在打包时用zip -X（保留属性）。tar 侧要注意，跨用户解压时--no-same-owner很重要，否则非 root 用户解压别人打的包会直接失败。

符号链接被展开。前面提过，zip 必须加-y。tar 默认是存链接本身，但如果加了-h（解引用）就会把目标内容打进去。做代码或配置打包时，一定要确认软链接的预期行为，不然包里可能凭空多出几个 GB。

磁盘空间不足，解压到一半。这类失败留下的是一堆半截文件，最麻烦的是你分不清哪些完整哪些不完整。稳妥做法是解压前先估算空间：unzip -l看解压后总大小，tar -tvf累加各条目大小。tar 的话可以直接tar -tvf x.tar | awk '{s+=$3} END {print s/1024/1024" MB"}'。空间留出 20% 余量，因为有些格式解压过程中会有临时开销。

超大文件处理。超过 4GB 的单个文件对 zip 是历史难题，需要 zip64 支持。现代版本基本没问题，但老工具和某些嵌入式环境仍会失败。遇到这种，优先换 tar 系列，没有 4GB 限制。另外注意文件系统本身，FAT32 单文件上限 4GB，这个换了格式也没用。

7z提示 "Can not open the file as archive"。九成是文件不完整或者根本不是 7z 格式。先用file看一眼真实类型，再用xxd看文件头。有一种情况是文件前面被加了别的数据（比如某些下载器的临时头），这时候需要先用dd跳过前 N 字节再解。

4.3 问题速查表

5. 场景化用法：把这层封装真正用起来

工具好不好用，最终看能不能嵌进实际流程。下面三个场景是我用得最多的。

5.1 日志与构建产物的归档

日志归档的特点是量大、变动频繁、需要定期清理。我的做法是按天切分，用 zstd 快速压，配合保留策略。

# 每天凌晨把前一天的日志压掉 find /var/log/app -name "*.log" -mtime +0 ! -name "*.zst" -print0 | while IFS= read -r -d '' f; do zstd -3 -T0 --rm "$f" -o "$f.zst" done

--rm是关键，压缩成功后删原文件，避免磁盘被双份占用。但要注意，如果压缩失败，--rm不会触发删除，这是安全的行为。构建产物类似，区别是产物通常要保留原始目录结构，用 tar.zst 打包更合适，解压后结构完整。

这套流程我用下来最明显的好处是 IO 压力小。gzip 单线程压大日志，磁盘和 CPU 总有一头闲着；zstd 加-T0能吃满多核，压缩时间缩短到原来的几分之一。日积月累，这个差距在运维响应速度上很直观。

5.2 交付给外部时的自解压与校验

给外部交付文件时，对方的环境你控制不了，可能没有 zstd，甚至没有 tar。稳妥方案是双份：一份 zip（兼容性最好，Windows 双击就能开），一份 tar.gz（Linux 通用），再附一个校验文件。

sha256sum deliver.zip deliver.tar.gz > SHA256SUMS

对方拿到后sha256sum -c SHA256SUMS一条命令验证完整性。传输出错、文件被截断这类问题，这一步能挡掉九成。我见过太多"解压失败"的投诉，最后查下来是传输过程中断了，加上校验就能把责任分清楚。

如果对方明确要求"双击就能用"，可以做一个自解压脚本：把 tar 包用 base64 编码嵌进 shell 脚本，脚本自己解码再解压。这种做法体积会增大约三分之一，但确实省事。生成方式大致是把tail -n +N script.sh | base64 -d | tar -xz这类逻辑写在脚本末尾，前面附上编码后的数据。

5.3 大文件与增量备份

真正的大文件备份，全量打包不现实，要增量。tar 的-g参数可以做快照式增量，配合压缩：

# 首次全量 tar -g snapshot.db -cf - /data | zstd -3 -T0 -o backup-full.tar.zst # 之后增量，只包含新增和变更 tar -g snapshot.db -cf - /data | zstd -3 -T0 -o backup-incr-$(date +%F).tar.zst

-g的工作原理是记录每个文件的修改时间和 inode，下次打包时跳过未变的文件。还原时要按顺序来：先全量，再依次叠加增量。顺序错了结果就是缺文件或者旧文件覆盖新文件。

这个方案有个局限：它靠文件属性判断变更，对文件名不变但内容原地修改的情况，能识别（因为 mtime 变了）；但如果在增量期间删除了文件，还原时不会自动删除对应文件，会留下"幽灵文件"。要彻底解决得用文件系统快照级别的方案，那是另一个话题了。日常备份场景里，这点不精确通常可以接受，但心里要有数。

6. 一点个人经验

用了这么久下来，我最深的一个体会是：压缩工具的选择应该由"数据用途"决定，而不是由"哪个压缩率高"决定。热数据、经常读的，用 zstd 低级别，速度快得让人愿意用；冷备、一年动不了几次的，用 xz 高级别，省下的空间是实打实的；要给别人、跨平台、不能出岔子，用 zip。这条判断标准比任何 benchmark 都实用，因为它把维护成本算进去了。

另一个心得是，不要把封装层做成黑盒。我见过一些团队做的包装脚本，出错时只吐一句"操作失败"，底层报错全被吞了，排查时只能靠猜。好的封装应该是：正常路径上帮你省事，异常路径上把原始信息完整透出来，最好再补一句"你可能需要做什么"。这两者不矛盾，只是需要写的时候多花点心思。

最后分享一个小习惯。我在每台常用的机器上都留了一个extract函数，不做任何花哨的判断，就是tar -xf加unzip加7z的三段兜底，按顺序试。这个简陋版本在这些年里解开的包，比任何精心设计的工具都多。有时候管用的东西，真的不需要很复杂。