1. 为什么我最后还是给压缩解压单独立了个工具位

压缩和解压这件事，看起来是最没有技术含量的活儿：unzip、tar -zxvf、右键解压，谁不会。但我自己统计过，一周里光是处理各种包就占了十几分钟，而且这十几分钟全是被打断的碎片时间——同事发来一个 zip，解出来一堆乱码文件名；线上导出的日志是.tar.gz，里面还套着一层.gz；别人给的素材包是 7z，本机没装解压软件；打个发布包给对面，tar 包里的软链接全变成了实体文件，体积翻了三倍。这些问题单拎出来都能解决，问题在于每次都要现场回忆该用哪个命令、哪个参数、哪个工具，脑子要切换一次上下文。

x-cmd-mod里的zuz模块干的就是这件事：把压缩和解压统一到一个入口，格式自动识别，参数尽量收敛，省掉"先看后缀再选命令"的这一步。它的定位不是替代 tar、unzip、7z 这些底层工具，而是当一层调度壳——判断这是什么格式、该调哪个后端、输出到哪儿、要不要建目录。对天天在终端里搬文件的人来说，这一层壳的价值比想象中大。

这篇内容适合三类人看：一是经常在命令行里处理压缩包的后端、运维、数据同学；二是刚上手 Linux、每次解压都要搜一遍命令的新人；三是想给自己攒一套稳定"文件搬运流程"的人。下面我会把 zuz 的设计思路、实际命令、踩过的坑、以及几种我每天都在用的组合写法拆开讲，命令都以我本地长期使用的形式给出，具体短选项请以你本机的zuz --help为准，因为这类工具的参数会随版本微调。

2. zuz 的核心思路：把"选工具"这一步交给程序

2.1 压缩格式的碎片化才是真正的麻烦源头

先把这个领域的现状说清楚，才能理解为什么要多这么一层。压缩格式不是"一种格式打天下"，而是历史包袱堆出来的生态：zip 因为 Windows 友好活得最好；tar.gz 是 Unix 世界的默认答案；tar.xz 压缩率高但慢，常见于发布包；zstd 这两年因为解压速度极快，在大目录快照和容器层里用得越来越多；7z 压缩率最高，但需要额外装后端；rar 则是历史遗留，能解不能压。每种格式背后对应一个不同的命令行工具，参数风格还各不相同。

这就带来了一个很实际的成本：你得先知道后缀，再回忆工具，再回忆参数。.tar.gz要用tar -zxvf，.tar.bz2要换成-jxvf，.tar.xz要-Jxvf，.zip用unzip，.7z用7z x，.gz单文件用gzip -d，.zst用zstd -d。记混一个字母，就是一次失败的解压和一次重新查文档。zuz 的第一层价值就在这里：它把"看后缀选工具"变成了程序的分支判断。

具体来说，它做的判断大致分三步。第一步看扩展名，这是最快的路径；第二步，遇到扩展名缺失、伪造、或者是多层后缀（比如backup.tar.gz.001）的情况，会去读文件头部的魔数（magic number），zip 是PK\x03\x04，gzip 是1f 8b，zstd 是28 b5 2f fd，xz 是fd 37 7a 58 5a 00；第三步，根据判断结果去调对应的后端程序。

注意：魔数判断不是万能的。有些老式自解压包（.exe 外壳包着的 zip）头部是 PE 结构，靠魔数识别不出来，只能靠后缀或者手动指定。遇到这种包别硬试，先用file命令看一眼真实类型。

2.2 自动建目录这个默认行为，救过我好几次

在讲格式之前，我想单独说说"解压到哪儿"这件事，因为它比格式识别更容易出事故。裸用tar -xvf或者unzip的时候，压缩包里的内容会直接铺在当前目录。如果包里没有顶层目录（很多打包工具默认就不加），你当前目录瞬间被几十个文件淹没，找都找不回来，更别提误覆盖同名文件。

zuz 的默认行为是解压前先建一个和压缩包同名的目录，把内容放进去。这个设计看起来很小，但它把"解压污染工作目录"这个高频事故直接掐掉了。我现在的习惯是：不管用哪个工具，解压前先ls或者-l看一眼包里的结构，确认有没有顶层目录；没有的话，一定手动指定输出目录。zuz 帮我省掉了这一步的犹豫，但习惯还是保留着。

2.3 和原生工具的关系：调度层，不是替代品

这里要说清楚一个容易误解的点：zuz 不是自己实现了 zip 和 tar 的编解码，它是调度层。压缩率、速度、兼容性这些底层指标，最终还是由后端决定的。所以你用它压出来的 zip，和用zip命令压出来的，本质上是一回事。它解决的是"调用体验"问题，不是"压缩算法"问题。

理解这一点很重要，因为它决定了你什么时候该用它、什么时候不该用。日常解压、打包、批量处理，用它最省事；但如果你要做一些底层控制，比如精确指定 zip 的压缩级别、控制 tar 的块大小、给 zstd 指定长距离匹配窗口，那就得回到原生工具，或者用 zuz 透传参数的方式调后端。我一般的原则是：常规操作走 zuz，需要精细调优才下沉到原生命令。

下面这张表是我自己整理的格式选择参考，日常打包前扫一眼就能定：

3. 装好之后先跑通这几条命令

3.1 安装与依赖检查

x-cmd 的模块体系是"按需加载"，zuz 作为其中一个模块，通常不需要单独安装，跟着主程序走就行。装完之后第一件事不是急着解压，而是先确认后端工具齐不齐：

zuz --help zuz -V

--help里会列出它支持的格式和后端依赖。如果某个格式的后端没装，解压到那个格式时才会报错，这时候补装就行。我自己机器上常备的后端是unzip、tar、gzip、zstd、xz，7z 和 rar 按需装——这两个不是每天用，装上占空间，不装又会在关键时刻卡住，我的做法是留着，反正是几十兆的事。

# 检查后端是否就位，缺哪个补哪个 command -v unzip tar gzip zstd xz 7z

提示：不要在生产机上临时装解压后端。很多精简镜像里连tar都是裁剪版，--exclude之类的高级参数可能不支持。上线前在目标环境里跑一次真实包的解压测试，比事后排查便宜得多。

3.2 解压：三种最常见的使用姿势

最基础的用法就是直接把文件丢给它：

zuz archive.tar.gz zuz package.zip zuz backup.7z

它会自动判断格式、自动建同名目录、自动选后端。执行完你会看到一个和包同名的目录，里面是解出来的内容。

第二种是指定输出目录，这是我在脚本里最常用的形式，因为脚本里不能依赖"自动建目录"这种隐含行为：

zuz -o ./output archive.tar.gz

第三种是只看不解，先确认包里有什么再决定要不要解：

zuz -l archive.tar.gz

-l这个动作我强烈建议养成习惯。原因有两个：一是确认包里有没有顶层目录，避免解压炸开；二是排查"解压出来一堆乱码文件名"的问题时，先看列表能立刻判断是编码问题还是文件本身有问题。

还有一个容易被忽略的场景：单文件压缩。比如app.log.gz这种，它不是一个归档包，就是一个文件被 gzip 压了。这种用zuz app.log.gz也能解，出来就是app.log，不会有目录。如果你的脚本里对输出结构有强假设，记得区分"归档包"和"单文件压缩"两种情况。

3.3 压缩：参数怎么选才不返工

压缩这块，我的经验是先把"给谁用"想清楚，再选格式，最后才调参数。很多人反过来，先纠结压缩级别，结果压出来对面打不开。

发给 Windows 用户，无脑 zip：

zuz -c deliver.zip ./dist

自己机器上做大目录快照，我基本都用 zstd，因为解压快得离谱，恢复的时候不折磨人：

zuz -c snapshot.tar.zst ./workspace

对外发布固定版本，用 xz，体积小，虽然压得慢，但压一次用很久：

zuz -c release.tar.xz ./build

需要保留软链接和权限位的时候，一定要用 tar 系格式，不要用 zip。这是我最容易踩的坑之一：项目里有个node_modules/.bin全是软链接，用 zip 打出来，解压之后软链接变成了实体文件副本，体积直接从几百兆涨到一个多 G，而且有些链接指向的文件在打包时根本不存在，压出来是坏的。tar 默认保留链接，zip 默认跟随链接，这个差别必须记住。

# 保留软链接、保留权限、保留属主信息 zuz -c -p release.tar.gz ./build

具体的短选项名称在不同版本上可能有差异，-p是不是"保留属性"要看 help。我的建议是：涉及权限和链接的打包，压完之后一定解压一次到临时目录，ls -l看一眼链接是不是还是链接、可执行位还在不在。这个验证动作花十秒，能省掉后面半小时的排查。

4. 四个真实场景的完整写法

4.1 批量解压一层目录下的所有压缩包

这是最典型的重复劳动。手动一个个解，二十个包就是二十次操作。批量处理的关键不是循环本身，而是三个细节：路径里有空格怎么办、解压失败要不要中断、输出目录怎么组织。

#!/usr/bin/env bash set -uo pipefail src_dir="./incoming" out_root="./extracted" mkdir -p "$out_root" find "$src_dir" -maxdepth 1 -type f \ \( -name '*.zip' -o -name '*.tar.gz' -o -name '*.tgz' -o -name '*.7z' \) \ -print0 | while IFS= read -r -d '' f; do base="$(basename "$f")" name="${base%%.*}" target="$out_root/$name" echo "==> $base -> $target" if ! zuz -o "$target" "$f"; then echo "!! failed: $f" >&2 fi done

几个点解释一下。-print0配合read -d ''是为了处理文件名里的空格和特殊字符，用for f in $(find ...)会在遇到空格时直接裂开，这个坑我踩过不止一次。set -uo pipefail里我特意没加-e，因为批量任务里单个包失败不应该中断整批，失败信息打到 stderr 就行，回头单独处理。name="${base%%.*}"是取第一个点之前的部分作为目录名，这样data.tar.gz会解到data而不是data.tar，避免目录名一层套一层。

注意：如果你的压缩包里有嵌套压缩包（常见于数据分发场景），不要图省事写递归解压。嵌套包的层级和命名没有统一约定，递归很容易解出一堆同名目录互相覆盖。我的做法是先解一层，看一眼结构，再决定第二层怎么处理。

4.2 打包时排除垃圾文件，把体积压下来

打包体积失控，八成是因为把不该打的东西打进去了：.git目录、node_modules、__pycache__、.DS_Store、各种.log和临时文件。一个几十兆的项目，带上这些能到几百兆。

zuz -c project.tar.zst ./project \ --exclude='.git' \ --exclude='node_modules' \ --exclude='__pycache__' \ --exclude='*.log' \ --exclude='.DS_Store'

排除规则有几个实践上的注意点。第一，--exclude匹配的是相对路径的模式串，写node_modules和写*/node_modules/*效果不一样，前者是精确匹配目录名，后者更宽泛，建议先在临时目录试一次，用-l看结果确认。第二，排除顺序有讲究，有些实现里后面的规则会覆盖前面的，所以"先全排除、再单独加回"这种写法要谨慎。第三，别用排除规则去处理"必须存在但内容不需要"的文件，比如空的占位文件，那应该用别的办法。

我自己的经验是维护一份项目级的排除清单，放在仓库里，打包脚本直接读，避免每次靠记忆临时敲。清单里固定加上这几类：版本控制目录、依赖缓存目录、构建产物目录、系统生成的隐藏文件、日志和临时文件。这五类基本覆盖了 90% 的体积浪费。

4.3 加密包和分卷包的处理

加密压缩包在企业环境里很常见，尤其是要过邮件网关或者走外部传输的时候。处理这类包有两个原则：密码不要出现在命令历史里，密码不要出现在脚本明文里。

# 从环境变量读，避免写进 history zuz -p "$ARCHIVE_PASS" -o ./out secret.7z # 或者从文件读，文件权限设成 600 zuz -p "$(cat ~/.archive_pass)" -o ./out secret.zip

命令行参数会被记录到 shell history，也会出现在ps的进程列表里，同机器上的其他用户能看到。所以密码走参数是下策，走环境变量是中策，走交互式输入或者受权限保护的文件是上策。具体 zuz 支持哪种读取方式，看 help；如果没有交互式读取，那就用文件加权限保护。

分卷包是另一个高频场景，尤其是超过几百兆的备份。分卷的坑在于"卷的顺序"和"卷的完整性"：少一个卷解不开，卷被改过名解不开，卷的顺序乱了也解不开。我的做法是先把所有卷收齐到同一个目录，确认命名连续（.001、.002这种），然后指定第一个卷开始解，工具会自动找后续卷。

ls -1 backup.7z.* zuz -o ./restore backup.7z.001

解分卷之前先确认磁盘空间，这个听起来很废话，但我真的见过解到一半空间满了，留下一个半成品目录，还得手动清理。粗略估算一下：分卷包总大小乘以 2.5 到 3，差不多是解压后需要的空间，压缩率高的格式系数更大。

4.4 管道流的玩法：不解压就看内容

有些场景你根本不需要落盘，只是想在压缩包里搜个东西或者看一眼某个文件。比如线上日志归档，你只想确认某个时间点有没有报错，没必要把几个 G 解出来。

# 从 tar.gz 里直接抽一个文件到标准输出 tar -xzOf archive.tar.gz path/to/app.log | grep -i "error" | head -50 # 列出包内文件，按大小排序，找出体积大头 zuz -l archive.tar.zst | sort -k1 -n -r | head -20

这种"流式"处理的价值在于省 IO 和省磁盘。对于我们这种磁盘常年紧张的环境，能不解压就不解压。tar的-O参数是把内容输出到标准输出而不是落盘，配合 grep、awk、sort 能拼出很多有用的临时分析命令。不过要注意，-O只适合单个文件或者小文件，抽大文件到管道里再 grep，CPU 和内存都会不太好看，这种还是老老实实解出来再处理。

5. 踩过的坑和排查思路

5.1 文件名乱码：几乎全是编码问题

Windows 上打的 zip，文件名默认用 GBK 或者 CP936 编码，解到 UTF-8 环境里就是一串问号或者方块。这是压缩解压领域最高频的问题，没有之一。

排查顺序是这样的。第一步，zuz -l看列表，如果列表里就乱，说明是包本身的文件名编码和当前环境不一致；如果列表正常但解出来乱，那问题在解压环节的转码。第二步，判断来源，Windows 打的包大概率是 GBK。第三步，用带编码参数的方式重解：

unzip -O cp936 package.zip -d ./out # 或者 7z x -mcp=936 package.zip -o./out

zuz 这类工具在检测到文件名不是合法 UTF-8 时一般会有提示，但自动转码这件事本身有风险——猜错了会得到更乱的结果。所以我的建议是：能不自动转就不自动转，先看提示，再手动指定编码重解一次，确认没问题再继续。

提示：自己往外发包的时候，尽量用 tar 系格式，tar 对文件名编码的处理比 zip 干净得多。如果对方只能用 zip，那就提醒一句"文件名是 UTF-8"，减少来回扯皮。

5.2 权限和软链接丢失：zip 的原罪

前面提过一次，这里展开说。zip 格式在设计上就没有完整保存 Unix 权限位和软链接的标准方式（虽然有扩展字段，但支持度参差不齐）。所以用 zip 打包一个带可执行脚本和软链接的目录，解出来大概率是坏的。

表现有三种：可执行文件变成不可执行，需要手动chmod +x；软链接变成实体文件，体积暴涨；软链接指向的目标不存在时，变成一个空文件或者干脆丢失。

解决办法只有一个：这类场景别用 zip，用 tar。tar 从设计上就是为 Unix 文件系统备份而生，权限、属主、时间戳、软链接、硬链接、设备文件都支持。

# 打包 tar -czf release.tar.gz ./build # 解包，注意 -p 保留权限 tar -xzpf release.tar.gz

如果交付对象确实只能用 zip，那就在包里附一个恢复脚本，解压后跑一遍，把可执行位补回去，把软链接重建出来。这活儿麻烦，但比让对方手动修要体面。

5.3 路径穿越：陌生压缩包先看再解

这是一个安全习惯问题。压缩包里的文件路径是可以带../的，也就是说一个恶意构造的包，解压时可能把文件写到你的主目录、写到系统目录、甚至覆盖配置文件。这类问题在各类工具的 CVE 里反复出现。

现代工具大多做了防护，解压时会拒绝绝对路径和带..的相对路径。但防护不是百分百，不同实现的行为也不一致。所以对来源不明的包，我的流程固定是三步：先-l列内容，看有没有奇怪的路径；再解到一个隔离的临时目录，不要解到工作目录或者家目录；确认内容正常之后再挪到目标位置。

mkdir -p /tmp/inspect && cd /tmp/inspect zuz -l /path/to/unknown.zip zuz -o ./unpacked /path/to/unknown.zip

这个习惯看起来啰嗦，但成本极低，收益是避免一次灾难。尤其是从聊天工具、邮件附件里收到的包，多花十秒看一眼列表，很值。

5.4 常见问题速查表

下面这张表是我这几年攒下来的，遇到问题先扫一遍，能省不少搜索时间：

6. 几条用久了才明白的实操心得

第一条，格式选择优先于参数调优。我见过太多人纠结 zstd 的压缩级别调到几，结果交付的时候对面根本装不了 zstd。先把"给谁、在什么环境用"定下来，格式定了，参数基本没什么可调的余地。日常场景里，压缩级别的收益远没有你想象的大，从默认级别往上调，体积可能只降几个点，时间翻倍。

第二条，打包一定要可复现。同一个目录，今天打的包和明天打的包，如果内容没变但哈希变了，那说明打包过程带进了时间戳或者顺序不稳定。做发布包的时候这个很重要，因为你要能证明"这个包就是那次构建的产物"。tar 有排序参数，也有统一的 mtime 归零技巧，这些细节在需要做完整性校验的场景里是刚需。

第三条，永远验证一次。压完解一次，解完看一眼。这个动作我坚持了很多年，救过的次数已经数不清了。验证不需要多复杂：解到临时目录，比对文件数量，抽查几个关键文件的内容和权限，齐活。十分钟的验证，换的是交付之后不用半夜被叫起来。

第四条，把常用组合写成脚本。批量解压、带排除规则的打包、分卷恢复，这三个我都有对应的脚本放在~/bin里，参数化之后调用。写脚本的过程本身就是一次梳理，你会发现自己在哪些地方一直靠记忆硬撑，哪些地方其实有更稳的写法。工具的价值不只是省一次输入，更是把"正确做法"固化成默认行为。

第五条，别迷信任何单一工具。zuz 好用，但遇到奇怪的包、奇怪的编码、奇怪的权限问题，该退回tar、unzip、7z、file的时候不要犹豫。工具是手段，把文件完整、正确地搬到该去的地方才是目的。我现在的状态是：九成场景用 zuz 一把过，剩下一成现场判断，哪种手段最直接就用哪种，不跟工具较劲。