上周帮人处理一批素材归档，他那台机器是精简环境：tar 有，gzip 有，zip 勉强有，7z 没有，遇到一个 .rar 的包直接卡住半小时。最后是换了一条统一入口的命令，格式判断、列目录、解压一次做完，他才反应过来——压缩解压这件事的麻烦从来不在算法，而在“我到底该敲哪个命令”。zuz就是冲这个麻烦来的，它是命令行工具集里的一个模块，职责单一到一句话能说完：压缩或解压文件。

这篇东西写给三类人看：一是天天在终端里跟各种归档包打交道、但每次都要翻历史命令的运维和开发；二是要把打包解包写进脚本、又怕踩坑的自动化同学；三是刚上手命令行、被tar czf和tar xzf搞晕的新人。我不会只告诉你“敲这条命令”，重点讲清楚每个选择背后的取舍、哪些参数是必须显式指定的、哪些坑是跨平台搬包时一定会遇到的。下面提到的具体子命令形态属于这类统一入口工具的常见约定，不同版本可能有差异，动手前先跑一次 help 输出核对，这个习惯比记住任何一条命令都值钱。

1. 压缩解压为什么值得单独封一条命令

1.1 格式碎片化把肌肉记忆撕成了好几套

先数一下日常要碰的东西：.tar.gz、.tar.xz、.tar.zst、.zip、.7z、.rar、.gz、.bz2、.xz、.zst，还有 Windows 那边流传过来的自解压包。每种格式背后是不同工具、不同参数风格、不同默认行为。tar的选项老派到不带减号也能跑，unzip的-d是指定目录，7z的-o后面不能有空格，zstd -d默认还会删掉源文件之外的判断逻辑跟你想象的不一样。人在这种环境里待久了，靠的是条件反射而不是理解，一旦换台机器、换个发行版、换个 BusyBox 环境，反射就失灵。

更麻烦的是“格式和工具不是一一对应”的。.tar.gz是两层：tar 负责归档，gzip 负责压缩。你敲gzip -d只能得到一堆.tar，还得再拆一次。.tgz是它的别名，.tbz2、.txz、.tzst同理。新手最容易在这里绕圈：明明解压“成功”了，目录里只多了一个.tar文件，以为工具坏了。

统一入口的价值就在这：把“识别 + 分派 + 调用底层工具”这三步收敛成一个动作，你只管说要压还是要解，剩下的交给它判断。这不是新技术，是减少决策点的工程学。

1.2 它做的事是收敛入口，不是重新发明压缩算法

这点必须说清楚，否则容易产生错误期待。这类模块本身不实现 DEFLATE、LZMA、Zstandard 这些算法，它做的是编排：看一眼文件后缀或者文件头，决定该调哪个后端，把参数翻译成后端认识的形式，再把结果和错误信息整理成人能看懂的样子。

所以它的能力上限取决于机器上装了什么。目标机器上有zstd二进制，.tar.zst就能处理；没有，就得报错或者降级。这一点在写自动化脚本时是硬约束——不要假设目标环境一定有全套后端，动手前先探测。

提示：任何“一条命令支持所有格式”的说法都要打个折。真正稳的做法是在脚本开头做一次能力探测，把可用后端列出来，缺什么就提前失败，而不是跑到一半才报错。

1.3 什么场景该用它，什么场景别硬上

适合的场景：临时处理下载下来的包、写一次性脚本、跨机器搬文件、给不熟命令行的同事准备操作入口、容器里做简单的构建产物打包。这些场景的共同点是“要求不高、频率不低、格式不确定”。

不适合的场景也得说：需要保留 ACL、扩展属性、稀疏文件、硬链接关系的时候；需要固实压缩（solid）把压缩率抠到极致的时候；需要分卷、加密、恢复记录的时候；需要精确控制每个条目的属主和权限位的时候。这些属于底层工具的强项，统一入口为了通用性通常会牺牲掉一部分精细控制。该下沉就下沉，别为了少记一条命令把交付质量搭进去。

我在实际项目里通常这么分工：日常打包解包走统一入口，交付给甲方的正式包走底层工具加显式参数，两套并存不冲突。

2. 一次调用背后的判断链：它怎么知道该干什么

2.1 后缀名和文件头，两条识别路线的取舍

识别格式有两条路。一条看后缀，快，零成本，但会被骗——把.zip改名成.tar.gz是常有的事，尤其是下载工具自动改名或者人工“修正”过后缀的文件。另一条读文件头魔数：zip 是PK\x03\x04，gzip 是1F 8B，xz 是FD 37 7A 58 5A 00，zstd 是28 B5 2F FD，7z 是37 7A BC AF 27 1C。魔数不会撒谎，但要打开文件读前几个字节，网络文件系统上会有额外延迟。

靠谱的实现通常是先看后缀做快速判断，后缀不认识或者后端调用失败，再回落到魔数嗅探。你自己写脚本时也该遵循这个顺序，但判断依据要以魔数为准。我踩过一次坑：批量处理脚本按后缀分派，结果一批从某渠道下载的包后缀全被改成了.zip，实际是 7z，脚本一路报“压缩包损坏”，查了两小时才发现是后缀骗人。

还有一个细节：.tar.gz这类双层格式要连续剥两层。先按 gzip 解开得到 tar 流，再按 tar 解析。有些实现会直接调tar的-z让它内部处理，有些会自己剥。对你来说没区别，但排错时要知道“这可能是两层的问题”。

2.2 压缩和解压怎么分派：显式动作比隐式推断可靠

最省事的交互是隐式推断：给一个目录就打包，给一个文件就解压。用起来爽，但脚本里很危险——目录和文件的判断在符号链接、挂载点、权限不足的情况下会出意外。所以写进脚本时我建议动作显式化：压缩用一个明确的子命令或参数，解压用另一个，别依赖推断。

典型的调用形态大概是这样（具体子命令名以 help 为准）：

# 压缩：把目录打成 tar.zst zuz pack -o release.tar.zst ./dist # 解压：解到指定目录 zuz unpack -C ./out release.tar.zst # 只看内容，不落盘 zuz list release.tar.zst

三件事里最被低估的是 list。养成“先列后解”的习惯，能避开后面 80% 的麻烦：包结构是不是多套了一层目录、有没有恶意路径、压缩包里到底有没有你要的那个文件、条目数量是不是异常——这些信息在解压前看一眼就全有了，解压后再去翻就晚了。

2.3 参数透传和逃生舱：通用入口的边界在哪

通用入口一定会遇到“这个参数后端支持但入口没暴露”的情况。好的设计会留透传通道，把不认识的参数原样递给后端；差的设计直接吞掉，让你怀疑人生。用之前花两分钟确认透传语法，比事后 debug 划算得多。

反过来，如果发现某次任务需要连续透传三四个参数，那其实是个信号：这个任务已经超出统一入口的舒适区了，直接调底层工具更清楚。别硬凑。

还有一层是错误信息的可读性。底层工具的报错经常是 “Unexpected EOF in archive” 这种，人不一定看得懂。统一入口通常会包一层，告诉你“文件可能不完整”或者“不支持该压缩方法”。看到这类包装过的错误，第一反应应该是回到原始文件做校验，而不是继续在工具层面折腾。

# 拿到包的第一件事：算校验和，和发布方给的对比 sha256sum release.tar.zst

这一步花三秒，能省掉后面半小时的“到底是文件坏了还是工具坏了”的扯皮。

3. 压缩这一侧：把“能打包”做成“可复现的打包”

3.1 归档和压缩是两件不同的事，先想清楚要哪个

很多人把这两个概念混着用，导致选型时抓不住重点。归档（archive）解决的是“把多个文件塞进一个容器，保留目录结构和元数据”；压缩（compress）解决的是“让字节数变少”。tar 只做归档不做压缩，gzip/xz/zstd 只做压缩不做归档，tar.gz是两者串联。zip 和 7z 是两者一体。

这个区分在实操中的意义是：如果你打包的目的只是传输和分发，压缩率不是首要目标，那选速度快的就行，.tar.zst是当前性价比很好的选择；如果目的是长期冷备，字节数直接影响存储成本，那就值得用.tar.xz把压缩率抠出来，多花的那点 CPU 时间在存储周期面前不值一提。

还有一个反直觉的点：压缩包不是备份。它没有版本、没有增量、没有校验恢复，一个字节损坏可能导致整个包报废（尤其是固实压缩）。归档包适合做交付物和快照，不适合做唯一的备份载体。

3.2 压缩级别、字典和线程：参数背后的资源账

级别参数几乎每个工具都有，但“级别高”不等于“更好”，它换的是 CPU 时间和内存。

以 xz 为例，预设级别直接绑定字典大小：-6是 8 MiB 字典，-9是 64 MiB 字典。压缩时占用的内存大约是字典的十倍量级，xz -9单线程压缩峰值能到六七百 MB。在 1 GB 内存的小机器上并发跑几个，直接 OOM。解压侧的内存需求小得多，通常是字典的几倍，但仍需注意。

zstd 的级别跨度更大，-1到-19，还有--ultra开更高的档。低级别快得离谱，高级别能逼近 xz 的压缩率。实际经验：日常用默认级别，存储吃紧时上到-15左右，再往上收益递减明显而时间成本陡增。

线程方面，现代工具都支持多线程压缩，-T0表示用满所有核。注意多线程压缩会削弱压缩率，因为分块并行后跨块的重复模式利用不上。前后端都要考虑这点。

这张表不是选型答案，是给你一个判断起点。真实决策里还要加上“对方能不能解开”这个条件——给 Windows 用户发.tar.zst，大概率会被退回。

3.3 排除规则和路径处理，最容易被忽略的一半

打包出问题，一半以上出在“该排除的没排除”和“路径不对”。

排除规则的生效顺序在不同工具里不一样。GNU tar 的--exclude是对其后的所有路径生效，如果你把它写在路径参数后面，可能完全不生效。稳妥写法是把所有排除项放在最前面，或者用--exclude-from从文件读，规则集中管理，可读性也好。

路径方面，两条铁律：用相对路径打包，用-C切换目录而不是拼长路径。

# 推荐：切到父目录，用相对路径打包，包内顶层是 project/ zuz pack -o project.tar.zst -C /path/to/parent project # 不推荐：绝对路径打包，解压时容易散一地在当前目录，甚至带出 /path/to/parent 的完整层级 zuz pack -o project.tar.zst /path/to/parent/project

绝对路径打包还有个隐患：部分工具解压时会尝试还原绝对路径，虽然现代 tar 默认会剥离前导斜杠，但这个行为依赖实现，跨工具时不可靠。

另一个常见需求是“包内目录名换成别的”。有的工具提供路径变换参数（tar 的--transform），有的不提供，那就只能先建临时目录做软链或者复制。别小看这个需求，交付包顶层目录叫dist还是叫project-1.2.0，对接收方来说是“一眼能不能看懂”的区别。

3.4 一份可以直接抄的打包脚本骨架

下面这段是我反复用过、改过几轮的结构，重点不在命令本身，在每个判断为什么放在那个位置：

#!/usr/bin/env bash set -euo pipefail NAME="${1:?用法: $0 <项目目录>}" OUT="${NAME}-$(date +%Y%m%d).tar.zst" EXCLUDES=$(mktemp) trap 'rm -f "$EXCLUDES"' EXIT cat > "$EXCLUDES" <<'EOF' .git .gitignore node_modules __pycache__ *.pyc .DS_Store .env EOF # 打包前先确认目录存在且非空，避免打出一个空包还以为成功 [ -d "$NAME" ] || { echo "目录不存在: $NAME" >&2; exit 1; } [ -n "$(ls -A "$NAME")" ] || { echo "目录为空: $NAME" >&2; exit 1; } zuz pack -o "$OUT" --exclude-from "$EXCLUDES" -C "$(dirname "$NAME")" "$(basename "$NAME")" # 打完立刻校验，确认包能被读出来 zuz list "$OUT" > /dev/null sha256sum "$OUT" | tee "$OUT.sha256" echo "完成: $OUT ($(du -h "$OUT" | cut -f1))"

三个设计点解释一下。set -euo pipefail保证任何一步失败都立刻停，不会带着半截状态继续跑。trap清理临时文件，脚本被中断也不留垃圾。打包后立刻list一次，这是最便宜的完整性校验——包写坏了在这一步就能发现，而不是等交付后对方解不开。最后同时产出校验和文件，接收方拿到两个文件就能自行验证。

--exclude-from的具体参数名同样以 help 为准，如果这个统一入口不支持从文件读排除规则，退而求其次用多次--exclude，但规则要写在一个变量里，别散落在命令中间。

4. 解压这一侧：安全、编码、覆盖三个老大难

4.1 目录穿越和符号链接，先看清单再落盘

压缩包是可以携带路径的。一个条目写成../../etc/cron.d/evil，天真的解压实现会老老实实往上跳两级写文件。这不是理论问题，公开的恶意样本里这类构造非常常见。现代 tar 默认会拒绝包含..的条目，但不是所有实现都这么严谨。

所以“先 list 后解压”不是洁癖，是基本防护。看什么：条目路径里有没有..、有没有以/开头、有没有异常长的路径、文件数量是不是和预期差得离谱。

符号链接是第二层风险。包内一个软链指向/etc，后续条目再通过这个软链写文件，就能绕过路径检查。稳妥姿势是解压到隔离目录，确认内容干净再搬：

mkdir -p /tmp/unpack-check zuz unpack -C /tmp/unpack-check suspicious.zip # 检查完再决定要不要合并到目标位置

如果包来源可信、体积又大（比如十几 GB 的数据集），可以跳过隔离直接用，但仍建议至少做一次list抽样。信任是有成本的，别把成本转嫁给事后排查。

4.2 文件名乱码：CP936、UTF-8 标志位和解压出来全是问号

这是跨平台搬包最容易撞上的问题，没有之一。现象是解压出来的中文文件名变成????或者一串乱码字符。

根因在 zip 格式的历史包袱上。zip 的文件名编码没有强制规定，只有一个“通用位 11”表示“这个文件名是 UTF-8”。Windows 上很多工具生成 zip 时不设这个位，文件名就按本地代码页存（简体中文环境是 CP936/GBK）。Linux 上的解压工具看到没有标志位，默认按自己的 locale 解码，通常是 UTF-8，两边对不上就出乱码。

三种处理路径：

一是让解压工具按 CP936 解码。部分unzip实现有对应选项，但不是所有发行版都带。

二是换一个对编码判断更聪明的工具。7z 系列在这块处理得相对好，或者用脚本手动转。

三是用编程语言兜底，Python 的 zipfile 可以手动指定编码重命名，适合批量修复：

import zipfile, os, shutil src = "bad-names.zip" dst = "fixed.zip" with zipfile.ZipFile(src) as zin, zipfile.ZipFile(dst, "w", zipfile.ZIP_DEFLATED) as zout: for info in zin.infolist(): # cp437 是 zipfile 的默认回落编码，先按它取原始字节，再按 GBK 解 try: raw = info.filename.encode("cp437") name = raw.decode("gbk") except (UnicodeEncodeError, UnicodeDecodeError): name = info.filename new_info = zipfile.ZipInfo(name, date_time=info.date_time) new_info.external_attr = info.external_attr new_info.compress_type = zipfile.ZIP_DEFLATED if not info.is_dir(): zout.writestr(new_info, zin.read(info))

这段的思路是“先还原字节，再换编码解”，比直接对乱码字符串做替换可靠得多。注意目录条目要单独处理，否则会丢空目录。

反过来的场景也有：在 Linux 上打包发给 Windows 用户，中文名同样会乱。这种情况下老老实实用 ASCII 文件名，或者在压缩包里附一个manifest.txt说明映射关系，比赌对方环境靠谱。

4.3 覆盖、合并和原子性：别让半截解压污染工作目录

解压到已有目录时，默认行为各工具不同：有的直接覆盖，有的跳过，有的交互式询问。在脚本里，交互式询问是最糟的，会卡住整个流水线。

我自己的规矩是：永远解压到新目录，确认无误后再决定怎么合并。

TARGET="./release-$(date +%s)" mkdir -p "$TARGET" zuz unpack -C "$TARGET" artifact.tar.zst

原子性方面有个现实问题：解压不是一个原子操作，中途失败会留下半截文件。如果直接解到目标目录，失败后你面对的是一个“看起来有内容但缺一部分”的目录，比空目录危险得多。先解到临时目录再整体mv过去，mv在同一文件系统内是原子的，这个模式值得养成习惯。

TMP=$(mktemp -d) trap 'rm -rf "$TMP"' EXIT zuz unpack -C "$TMP" artifact.tar.zst # 成功后才合并 rsync -a "$TMP"/ ./target/

rsync -a而不是cp -r，因为前者保留权限和时间戳，而且支持增量，重复执行成本低。

4.4 权限位、时间戳、属主：跨机器搬包必查的三项

解压出来的文件权限不对，是第二高频的“玄学问题”。典型表现：脚本文件丢了可执行位，执行时报 Permission denied。

tar 格式本身是保存模式位的，但解压时是否还原取决于两点：执行解压的用户身份，以及有没有显式要求保留权限。普通用户解压时，权限位通常会被 umask 修剪；root 解压则倾向完整还原，这也是为什么“用 sudo 解压后再用普通用户跑”会出权限问题。

zip 在这块更弱。标准 zip 并不保存完整的 Unix 权限位，需要在创建时用额外字段记录，且解压端要显式要求还原。跨平台时基本可以认为“权限信息丢失”。

时间戳同理。tar 保留秒级 mtime，zip 因为沿用 DOS 时间格式，只有 2 秒精度，且时区处理容易出偏差。如果你的构建流程依赖 mtime 判断新旧（比如 make），用 zip 中转可能引发意外的重新编译。

属主信息在跨机器时基本没意义——对方机器上没有对应的用户 ID，还原出来的可能是个陌生账号。除非你明确知道目标环境一致，否则解压时应当忽略属主，只保留权限和 mtime。

提示：交付前自己先解压一遍到干净目录，跑一次关键文件的可执行性检查，这一步能挡掉绝大多数“对方那边跑不起来”的返工。

5. 和 tar、zip、7z 摆在一起比：它不是替代品

5.1 能力对照：各有所长，别指望一个打十个

看这张表的方式是：格式覆盖和参数简洁是统一入口的强项，元数据精细度和压缩率是底层工具的强项。它们不构成竞争关系。

5.2 组合拳：前置判断用它，正式打包用底层工具

我在实际流程里是这么分工的：不确定格式的、一次性的、临时的解压，走统一入口，省时间；正式的发布包，走tar加显式参数，把--exclude、--transform、权限处理都写死，保证每次产出可复现。

一个典型的发布脚本片段：

# 第一阶段：用统一入口做快速核对，确认收到的构建产物结构对 zuz list build-output.tar.gz | head -20 # 第二阶段：用底层工具做正式包，参数显式，结果可复现 tar \ --exclude='*.map' \ --exclude='.git*' \ --owner=0 --group=0 --numeric-owner \ -C build-output -cf - . \ | zstd -T0 -15 -o release.tar.zst # 第三阶段：回到统一入口做验证，确认包可读 zuz list release.tar.zst > /dev/null && echo "包结构校验通过"

注意第二阶段里的--owner=0 --group=0 --numeric-owner，这组参数的作用是把包内属主统一成 0/0。对容器镜像和分发场景很有价值，避免解压端出现莫名其妙的 UID 归属。这个细节在用统一入口的默认参数时通常拿不到，必须下沉。

5.3 容器和精简镜像里的取舍

容器镜像追求体积，基础镜像里往往只有 BusyBox 提供的精简版tar，很多高级参数不支持，zstd可能压根没装。这时候统一入口能不能用，完全取决于镜像里有没有对应后端。

我的做法是构建阶段和多阶段产物分离：在构建阶段用完整镜像，随便装工具；最终镜像只保留运行时必需的东西，压缩解压这些活全部在构建阶段做完。这样既不影响最终体积，又能用上完整的工具链。

如果确实需要在运行期解压（比如启动时解压配置），那就老老实实在镜像里装最小可用的后端，别指望“通用入口自带所有能力”。检查方式很简单：

# 探测后端可用性，缺什么提前知道 for cmd in tar gzip xz zstd unzip 7z; do command -v "$cmd" >/dev/null 2>&1 && echo "OK $cmd" || echo "MISS $cmd" done

这段探测脚本放在容器启动脚本或者 CI 的第一步，能让“解压失败”这类问题从运行期提前到准备期。

6. 排错实录：五个踩过的坑和完整排查链路

6.1 解压显示成功，目录却是空的

第一次遇到这个现象我以为是工具的问题，查了半天才发现是 inode 耗尽。磁盘df -h看着还有空余，但df -i显示 inode 用了 100%。一个包含几十万个小文件的压缩包解压时，每个文件占一个 inode，df -h完全看不出来。

排查顺序应该是这样：先df -h看空间，再df -i看 inode，两者都正常再看是不是解压到了错误的目录（pwd确认一下，别笑，-C参数用错位置的情况真实存在），最后看权限——子目录不可写时，某些工具会静默跳过而不是报错。

还有一个变体：解压到的是一个挂载点上，而挂载点本身已经满了或者只读，报错信息被工具吞掉，只留下一句“完成”。所以脚本里解压后必须验证，不能只看退出码。

zuz unpack -C "$TARGET" big.tar.zst [ -n "$(ls -A "$TARGET")" ] || { echo "解压结果为空，检查磁盘/inode/权限" >&2; exit 1; }

6.2 同一个包在两台机器上解压结果不一样

这个问题最能耗时间，因为“不一样”往往是很细微的：文件权限不同、时间戳差几个小时、目录里多出一些隐藏文件。

权限差异的根因通常是 umask。两台机器 umask 一个是 022 一个是 002，解压出来的组权限就不一样。临时对齐用umask 022前缀，长期靠环境统一。

时间戳差异的根因是时区和精度。zip 的 DOS 时间格式不带时区信息，解压端按本地时区解释，跨时区就差出几小时。如果流程依赖时间戳，别用 zip 中转，或者在解压后统一 touch 一遍。

隐藏文件差异的根因是 macOS。在 mac 上打包会额外生成__MACOSX目录和._前缀的资源叉文件，Linux 上解压看着就是一堆垃圾。打包时设置COPYFILE_DISABLE=1能抑制大部分，或者用--exclude='._*' --exclude='__MACOSX'清理。这类差异在“我这能跑对方那不行”的问题里占比很高，第一反应就该怀疑平台差异。

6.3 压缩包比原文件还大

看到这个先别怀疑工具。已经压缩过的数据（jpg、mp4、png、pdf、其他压缩包）再做一次压缩，绝大多数情况下几乎没有收益，反而因为要加上格式头和块结构，体积略增。

判断方法很简单：看文件类型分布。如果目录里主要是媒体文件或者已经压缩过的归档，压缩率上不去是正常的。这种情况正确的做法是不压缩，只归档：

# 只归档不压缩，速度快，体积约等于原始大小加一点开销 tar -cf bundle.tar ./media-dir zstd -1 -T0 bundle.tar -o bundle.tar.zst

更聪明的做法是混合处理：对文本、日志、源码这些高压缩比的内容认真压，对已压缩的二进制直接跳过。有些工具支持按文件类型设不同策略，如果统一入口没这个能力，就手工拆成两组分别处理再合并，虽然麻烦但收益实在。

另外提醒一句：压缩率异常低有时候是内容本身有问题的信号。比如一个本该是文本日志的文件实际是二进制乱码，或者一个目录里混进了超大临时文件。看到压缩率不符合预期，顺手du -sh *排个序，经常能发现意外混进来的东西。

6.4 打包时把 .git 和 node_modules 全卷进去了

这个坑我踩过不止一次，根因几乎都是排除规则写在了错误位置，或者规则语法不对。

排查链路：先用list看包内容，确认到底进去了什么；再检查排除规则的写法——--exclude=.git和--exclude='.git/'在某些实现里效果不同，前者可能只排除名为.git的文件而不排除目录；最后检查位置，很多工具的排除参数是对其后出现的路径生效，写在路径后面等于没写。

稳妥做法是把排除规则集中到一个文件里，用--exclude-from引用，同时在打包后用list做一次断言检查：

zuz list bundle.tar.zst | grep -E '(^|/)\.git(/|$)' && { echo "错误：.git 目录被打进包了" >&2; exit 1; }

这种“打完立刻断言”的写法，比事后靠人眼检查可靠得多。规则会变，人会忘，脚本不会。

6.5 解压到一半进程被 kill，留下一堆残骸

磁盘满、超时、OOM Killer、手动 Ctrl+C，都会造成这个局面。tar 这类流式格式不支持断点续传，中断了只能重来。但重来之前有个关键动作：清理残留。

如果直接对着同一个目录重跑，可能出现“部分文件是上次的旧版本，部分是这次的新版本”的混合状态，比彻底失败更难排查。所以流程应该是：失败后先删掉目标目录（前提是解压到专用子目录），再重跑。

TARGET="./workspace/extract" if ! zuz unpack -C "$TARGET" big.tar.zst; then echo "解压失败，清理残留后重试" >&2 rm -rf "$TARGET" zuz unpack -C "$TARGET" big.tar.zst fi

如果包大到重跑成本无法接受，那就该考虑用支持分卷的方式在生产端切分，或者干脆换成能续传的同步方案。压缩包本身不是为“可恢复”设计的，硬要它承担这个职责是选型错误。

7. 把它接进日常流水线：别名、函数和批量归档

7.1 一份可以直接抄进 shell 配置的函数

天天敲完整命令太低效，但别用别名做复杂参数拼接，容易在引号上翻车。用函数更稳：

# 安全解压：解到独立目录，先列后解，失败自动清理 x() { [ -f "$1" ] || { echo "不是文件: $1" >&2; return 1; } local tmp tmp="$(mktemp -d "${TMPDIR:-/tmp}/x.XXXXXX")" || return 1 echo "--- 包内容预览（前 20 条）---" zuz list "$1" | head -20 echo "--- 解压到: $tmp ---" zuz unpack -C "$tmp" "$1" || { rm -rf "$tmp"; return 1; } echo "$tmp" } # 打包：带默认排除规则 p() { local src="${1:?用法: p <目录> [输出名]}" local out="${2:-$(basename "$src").tar.zst}" zuz pack -o "$out" \ --exclude='.git' --exclude='node_modules' --exclude='__pycache__' \ --exclude='.DS_Store' --exclude='*.pyc' \ -C "$(dirname "$src")" "$(basename "$src")" zuz list "$out" > /dev/null && echo "OK: $out" }

x有几个设计点值得说。它把解压目标隔离到临时目录，避免污染当前目录；先打印前 20 条内容，让你有机会中断；失败时清理临时目录，不留垃圾；成功时输出路径，方便后续命令用$(x file.zip)接住。这个模式用了几年，救回过不止一次。

p的重点是把排除规则固化成默认值，避免每次都靠记忆。

7.2 日志归档：压缩策略比压缩率更重要

日志归档是压缩最典型的生产场景，也是最容易做成“占空间但没人看”的场景。我踩过的教训：一开始追求压缩率，全用最高级别，结果一次归档要跑四十分钟，赶上磁盘告警时根本来不及，最后只能临时删日志腾空间。

后来改成按热度和体积分层：

执行脚本大致是这样：

#!/usr/bin/env bash set -euo pipefail LOG_DIR=/var/log/app ARCHIVE_DIR=/data/log-archive find "$LOG_DIR" -maxdepth 1 -name '*.log' -mtime +7 -print0 \ | while IFS= read -r -d '' f; do base="$(basename "$f" .log)" zuz pack -o "$ARCHIVE_DIR/${base}-$(date +%Y%m%d).tar.zst" -C "$(dirname "$f")" "$(basename "$f")" rm -f "$f" done

这里find -print0加while read -d ''的组合是为了正确处理文件名里的空格，-mtime +7保证只归档足够老的。别看这几行简单，文件名带空格的处理是批量脚本里最常见的翻车点。

7.3 给别人交付压缩包时，把“对方能不能解开”放在第一位

这条纯粹是经验。技术上一万人能解开.tar.zst，但你的接收方可能只有资源管理器。交付包选型的第一约束是接收方的环境，不是你的偏好。

给 Windows 用户：用.zip，文件名全英文，目录层级不超过三层，附一个README.txt说明里面是什么。给非技术同事：.zip，目录名用中文但保持简短，避免超长路径。给同类技术团队：.tar.zst或.tar.gz，附 SHA256。跨组织、不确定对方环境：.zip永远是安全牌。

还有一个小细节：交付包里不要包含隐藏文件。.DS_Store、.gitignore、.env这些东西对接收方是噪声，其中.env还可能带敏感配置，属于严重事故。打包前的排除规则里必须有这一条，而且要先list确认。

最后分享一个我坚持了很多年的习惯：任何交给别人的压缩包，打包完成后自己解压一遍到干净目录，把里面的关键文件打开看一眼。这个动作花不了一分钟，但能挡住“发出去的包里少了个文件”“配置文件是开发环境的”这类尴尬。工具再顺手，也替代不了那一次亲手验证。