最近不少朋友问我，Linux 下到底怎么用 zip 命令压缩文件夹，说实话，这个问题看起来基础，但真用起来坑还挺多，尤其是从 Windows 习惯切过来的人，最容易在路径、编码、递归这几件事上翻车。这篇就把我在实际环境里折腾 zip 压缩文件夹的经验完整梳理一遍，覆盖基础语法、常用参数、目录递归、排除文件、加密、分卷压缩、中文乱码、伪加密排查这些点，给刚开始接触 Linux 的读者一份可以直接照着抄的操作手册，也让已经有经验的运维朋友看看有没有自己忽略的细节。
先用一句话概括：Linux 下压缩文件夹的核心命令是zip -r 目标.zip 文件夹名，-r表示递归处理子目录，不加它，zip 就只打包空目录本身，不往里面走。这个命令背后的逻辑、参数选择、踩坑点，才是这篇真正要讲清楚的东西。
1. 为什么在 Linux 里选 zip 而不直接用 tar
1.1 tar 和 zip 的本职工作完全不同
很多刚从 Windows 转过来的朋友，一看到 Linux 下压缩就下意识想找“右键压缩”，结果发现桌面环境不一定有，命令行里又听说要用 tar，就蒙了。其实搞清楚 tar 和 zip 的区别，选择就自然清楚了。
tar 的英文全称是 Tape Archive，历史可以追溯到磁带备份年代，它本身设计出来是为了“归档”，也就是把一堆文件和目录拼成一个文件，方便备份或传输。tar 默认根本不压缩，只是在后面追加文件内容，所以 tar 包通常叫“归档包”更准确。你看很多软件发布的是.tar.gz，这是先 tar 归档、再用 gzip 压缩的复合产物。
zip 就不同，它的设计从根上就是“压缩格式”，每个文件都会被单独压缩存储，然后打包在一起。zip 格式里每个文件都有自己的压缩数据、文件名、时间戳、权限位，相当于一个既归档又压缩的容器。
聊到这，结论就出来了：如果你只是想把文件夹打包给同一台 Linux 服务器上的其他用户，或者做简单的备份，tar 更合适，因为它能完整保留文件的属主、属组、权限、ACL、扩展属性。但如果你的目标是把文件夹传到 Windows 机器上、发给客户、上传到某些网盘或平台，zip 就是更通用的选择，Windows 自带资源管理器就能直接解压，不需要额外装软件。
1.2 什么时候必须用 zip 的场景
我总结了一下这些年实际遇到的场景，下面这些情况下 zip 几乎是唯一合理的选择：
- 目标用户是 Windows/Mac 用户，你没法预期对方装了没有 7-Zip、WinRAR、PeaZip 这类工具。
.zip是 Windows 和 macOS 都能原生识别的格式，几乎零门槛。 - 需要把文件上传到某些 Web 系统、对象存储、网盘，这些平台往往只识别 zip，或者对 zip 的在线解压支持最完善。
- 文件要在多个平台之间来回传，比如开发环境在 Linux 下打包，交付物要在 Windows 下解压、修改、再回传。zip 格式内部每个文件自带 CRC32 校验，出错容易定位。
- 处理包含大量小文件的目录，zip 默认的 Deflate 算法在压缩小文件时表现尚可，而且逐个文件压缩的特性决定了你解压时可以“点谁解谁”，不用像 tar 那样整个流式解压。
还有一点很关键：zip 格式有 Central Directory（中央目录），文件索引信息全部集中在包末尾，所以一个 zip 包损坏时，往往可以通过修复中央目录来抢救一部分文件。tar 则是流式拼接，中间坏一块，后面的文件基本全废。就这一点，zip 在很多“必须交付”的场景里就更让人安心。
所以我的选型建议很朴素：自己归档备份用 tar，要交付给别人、跨平台互传，用 zip。这篇主要围绕后者展开。
2. zip 压缩文件夹的核心语法与参数拆解
2.1 最小可用命令与常用参数速查
先给新手一个速查表，这些都是我日常用得最多的参数，每个都标注了实际用途：
| 参数 | 作用 | 实际用法示例 |
|---|---|---|
-r | 递归压缩子目录，压缩文件夹必加 | zip -r backup.zip /data/logs |
-q | 安静模式，不打印逐个文件的过程 | zip -rq backup.zip /data/logs |
-m | 压缩后删除原文件，移动而非复制 | zip -rm backup.zip /data/logs |
-e | 交互式设置加密密码 | zip -er backup.zip /data/logs |
-P | 直接在命令行指定密码（有安全隐患） | zip -rP 'Pass123' backup.zip /data/logs |
-x | 排除指定文件或通配符模式 | zip -r backup.zip /data -x "*.log" |
-y | 保存符号链接本身，而不是链接指向的内容 | zip -ry backup.zip /path/to/symlink |
-s | 创建分卷 zip，参数为卷大小 | zip -r -s 100m backup.zip /data |
-0 | 只存储不压缩，速度最快 | zip -r -0 backup.zip /data |
-9 | 最大压缩比，速度最慢 | zip -r -9 backup.zip /data |
如果你只记住一条，就是-r。我见过太多人用zip backup.zip /data/logs之后发现打包出来的 zip 只有空目录甚至啥也没有，就是因为忘了-r。zip 命令的默认行为是只压缩命令行里直接列出的文件，遇到目录不会自动遍历进去，这个坑必须刻在脑子里。
2.2 压缩文件夹时最关键的递归和路径问题
递归解决了，路径问题往往紧接着就踩上去。我举个具体例子说明：
cd /home/user zip -r project.zip project这个命令执行后，zip 包里的路径是project/...。如果你在/home/user/project目录内部执行zip -r /tmp/project.zip .，zip 包里的路径就变成./...，解压出来路径结构就不同了。
这个问题直接决定了解压后的顶层目录结构。如果你把包发给别人，通常希望解压后有个顶层文件夹包着，方便人家管理，那就应该从上级目录切入打包目标文件夹本身。如果你希望解压后直接散落在当前目录，那就进入目标文件夹里用.打包。
我自己习惯的做法是这样：
cd /home/user && zip -r project.zip project而不是cd /home/user/project && zip -r ../project.zip .。前者的包里有project/顶层目录，解压后形成独立文件夹，很干净。后者的包内容路径是散开的，别人一解压，一堆文件直接泼到当前目录，体验很差。
还有一点，绝对路径要小心。如果你用zip -r backup.zip /home/user/project，zip 会警告你“绝对路径会被去掉斜杠”，打包后的路径是home/user/project/...。虽然能解压，但带来两个隐患：一是路径结构带着一串层级，二是绝对路径可能触发 zip slip 类似的路径穿越风险，解压工具处理起来也敏感。所以压缩时尽量先 cd 到压缩目录的父级，再用相对路径打包，这样包内路径干净，别人解压也安全。
2.3 排除文件、符号链接与时间戳的高级处理
实际工作中，压缩整个目录往往不需要所有内容。最常见的是要排除日志、临时文件、缓存、node_modules 这类动不动几百兆的东西。-x参数就是干这个的，但它里面用通配符时有个细节要注意：
zip -r backup.zip /data/app -x "*.log" -x "cache/*" -x "*/logs/*"-x后面跟的模式是相对于包内路径来匹配的，不是相对于当前 shell 路径。所以"*.log"可以匹配任意层级下所有.log结尾的文件，而"cache/*"只匹配包内顶层cache/目录下的内容。想要全局排除，别怕麻烦，写"*/cache/*"更稳妥。
符号链接在 zip 里也是个容易闹情绪的点。默认情况下 zip 会把符号链接指向的目标文件内容读取后压缩进去，这通常不是你想要的结果。比如有个软链接current -> release_v2.0，默认压缩会把整个release_v2.0目录内容复制进去，包体积爆炸。此时用-y参数让 zip 保存符号链接本身，解压后链接还在，指向原目标。
这个取舍要看场景。如果是备份实际数据文件，默认行为（追目标）反而正确。如果是打包程序目录、希望解压后符号链接依然生效，就得加-y。我先说结论，后面实操章节会再演示。
时间戳这块，zip 默认会保留文件修改时间，但访问时间不会保留。如果你想在压缩时统一重置所有文件时间戳到某个固定时间点，实现可复现构建，zip 本身没有直接的单参数实现，我一般是先用touch统一改时间，再压缩。目前多数场景用不到，但如果你做 CI 发布包，这个思路值得知道。
3. 完整实操：一条项目备份命令的前后细节
3.1 实操场景：打包带日志和缓存的网站目录
纸上谈兵没意思，我模拟一个最常见的场景：你有一台服务器，网站程序在/opt/myapp，里面有源码、runtime 日志、缓存文件、上传目录，现在要做一次完整备份并把包下载到本地 Windows 电脑检查。
先看目标目录结构：
/opt/myapp ├── app.py ├── config.ini ├── static/ ├── runtime/logs/ # 大量日志，不需要备份 ├── cache/ # 可重建缓存，不需要备份 └── uploads/ # 用户上传文件，必须备份目标：打一个包含全部内容的压缩包，但排除runtime/logs和cache，包名带日期，输出到/backup。我的执行记录如下：
cd /opt zip -rq /backup/myapp_$(date +%Y%m%d).zip myapp \ -x "myapp/runtime/logs/*" \ -x "myapp/cache/*"拆解一下这条命令：
cd /opt是保证包内路径是myapp/...，解压后就是一个完整目录。-r递归目录，必须有。-q安静模式，避免几百个文件刷屏。$(date +%Y%m%d)生成如myapp_20250617.zip的带日期文件名，这是备份文件命名的基本素养。-x排除的路径要注意，我写的是myapp/runtime/logs/*而不是runtime/logs/*，因为包内路径带myapp/前缀。如果你不确定，可以先压缩后用unzip -l查看包内路径，再调整排除模式。
3.2 压缩后立刻验证包内容和完整性
命令跑完别急着传输，先验证。这是我在生产环境养成的习惯，救过我不少次。
# 1. 查看压缩包内文件列表和路径 unzip -l /backup/myapp_20250617.zip # 2. 测试完整性，不实际解压 unzip -t /backup/myapp_20250617.zipunzip -l的输出里有个容易忽略的细节：每个文件后面有时间戳和大小，你可以快速核对关键文件是否在包里，路径是否正确。unzip -t会对所有文件做 CRC32 校验，输出到末尾出现No errors detected in compressed data of /backup/myapp_20250617.zip.就说明包是完整的。
有一次我在交付前忘了加-r，打包出来包内只有第一层目录，unzip -l一眼就看到了问题，几百兆的备份文件其实是个残疾包。所以我建议把unzip -l固定放进你的验证流程，别跳过。
再补一点：如果你只想验证完整性和实际解压，可以用unzip -qo /backup/myapp_20250617.zip -d /tmp/test_extract，-d指定解压目录，避免把文件散到当前目录。-o表示覆盖已存在文件，-q安静模式。解压后du -sh /tmp/test_extract对比一下源目录大小，心里更有底。
3.3 压缩率和性能的平衡选择
zip 默认的压缩级别是 6，这个级别在绝大多数情况下是性价比最高的。但不同文件类型对压缩级别的敏感度差很多：
- 文本、日志、JSON、代码这类文本文件，压缩级别从 0 提到 9，体积可能从 100M 减到 20M，差距巨大，值得用
-9。 - 图片、视频、音频、数据库二进制文件，基本都是已经压缩过的格式，再压也是徒劳。视频文件压缩率几乎为 0，白耗 CPU。对这类目录我直接
-0只打包不压缩，速度能快十倍以上。
我做一个对比实验就能看得更清楚。同样的一个目录，里面有文本日志和几个 MP4 视频：
# 默认级别 time zip -rq default.zip /data/sample # 最高压缩比 time zip -r9q best.zip /data/sample # 最快模式 time zip -r0q fast.zip /data/sample实测结果往往是：default.zip和best.zip体积可能只差 3% 到 5%，因为视频占了大部分体积，这部分根本压不动。但best的耗时可能是default的三到五倍。所以我现在的策略是：
目录里文本文件居多、对体积敏感，用
-9；目录里媒体文件居多的备份场景，直接用-0；普通日常打包，用默认级别即可，不用纠结。
顺带提一句，zip命令在多核 CPU 下的表现其实一般，它是单线程的。如果你有一台多核服务器要压缩超大目录，觉得 zip 太慢，可以先考虑用7z或pigz（并行 gzip），这类工具支持多线程，压缩速度能拉满。但如果你必须交付 zip 格式，也可以先用7z快速压缩出7z包，再在目标机器上解压后重新打 zip——这个流程有点绕，所以我个人还是尽量直接用 zip，除非数据量真的到了 GB 级以上需要赶时间的程度。
4. 压缩包加密、伪加密与跨平台兼容性那些坑
4.1 加密压缩的正确姿势
zip -e是交互式加密，命令运行后会提示你输入两次密码，适合不希望在 shell 历史里留下密码的场合：
zip -er secret.zip /opt/myapp/private-P是直接在命令里带密码，虽然方便，但几个隐患非常明显：
- 密码会记录在 shell history（
~/.bash_history）里，相当于明文泄露。 - 服务器上的其他用户通过
ps aux在压缩瞬间就能看到完整命令行，包括密码。 - 密码变成脚本参数后，脚本文件本身就是个隐患。
所以我的习惯是：脚本里一律不用-P，宁可写交互式或用 expect/密钥文件方案。其实更推荐先用普通方式压缩，再用zip -e重新加密一次，这种流程至少不会让原始密码反复出现在命令行里。
zip 的加密默认用的是 ZipCrypto，这是一种比较老的算法，安全性有限，只适合防君子不防小人的场景。如果你的文件真的很敏感，zip 格式本身就不太适合承载重要机密，建议直接用 GPG 加密或 7z 的 AES-256。这个观点我在很多场合说过：zip 加密是“方便分享”的选项，不是“安全存储”的选项。
4.2 zip 伪加密：表面要密码，其实随时能解
搜索引擎热词里“zip伪加密”我特别注意到了，实际工作中遇到不少。所谓伪加密，指的是 zip 文件头部有一个通用位标志（general purpose bit flag）里的加密位被置了 1，但实际上文件数据本身根本没有加密，或者只加密了文件名、没加密文件内容。有些解压工具（包括 Windows 资源管理器）看到加密位就直接卡住让你输密码，输错了还打不开。
我在排查这类文件时，一般用下面的流程：
# 查看 zip 文件头部信息 unzip -lv suspicious.zip # 看每个文件的加密标记位 flags zipinfo -v suspicious.zip | grep -E "file security status|encryption"如果zipinfo显示的加密状态和实际解压表现不一致——比如提示要密码但用一个小工具或文本编辑器能看到 ZIP 内部的文件名列表是明文——那基本可以断定是伪加密。遇到这种包，处理方式很简单：不用去执着输密码，换个解压工具（比如 7-Zip 命令行）往往能直接忽略伪加密标志位把文件拖出来。正经来说，伪加密多用于某些分享场景里“防普通用户”的目的，但你在生产环境收到这样的包要多留个心眼，文件内容不一定安全。
这里必须插一句重点：我绝不建议去研究怎么暴力绕过别人包的真实密码，那是另一码事。明白伪加密的原理只是为了理解 zip 格式的加密机制，避免在项目交付中被这种文件卡住浪费时间。
4.3 中文文件名乱码：Windows 和 Linux 的天然冲突
跨平台传输最烦的问题之一就是中文文件名。Windows 的中文环境文件名编码主要是 GBK/GB18030，而 Linux 桌面和压缩工具大多默认 UTF-8。这就导致你看到一个包，在 Linux 下压缩得好好的，文件名在 Windows 解压后变成乱码。反过来，Windows 下压的中文文件名推到 Linux 解压，一样乱码。
zip 本身在规范里其实支持 UTF-8 文件名标记位（bit 11），但不同工具实现差异很大。Linux 的 zip 命令从 3.0 版本开始，默认就会尝试把文件名编码为 UTF-8 并设置标记位。如果你在 Windows 上解压时依然乱码，通常是 Windows 的压缩/解压工具版本太老，不识别 UTF-8 标志位，硬按本地 ANSI 编码解析。
解决办法有几种，我按推荐程度排一下：
# 1. 打包时显式指定 UTF-8 文件名编码 zip -r -UN=UTF8 backup.zip /data/files # 2. 解压时让 unzip 把 GBK 文件名转成 UTF-8 unzip -O GBK backup.zip -d /target/dir-O GBK这个参数很实用，很多从 Windows 传过来的老包（那些非 UTF-8 文件名标记的老 zip）在 Linux 下乱码，用unzip -O GBK就能正常解出中文名文件。Ubuntu 自带的 unzip 版本 6.0 以上大多支持-O，但一些精简版系统可能需要额外安装unzip包的版本才支持。
如果你要批量处理很多老 zip 包，建议先unzip -l看看文件名是不是乱码，再用-O GBK解压。这个小技巧在跨平台交付场景里能省下一大串“文件名怎么全是乱码”的问题。
5. 分卷压缩、修复与备份场景的进阶实践
5.1 大文件分卷压缩与限制体积
把一个 1.2GB 的文件夹塞到只能传 500MB 一包的环境里，就需要分卷。zip 的-s参数可以用：
zip -r -s 500m bigdata.zip /data/bigfiles注意输出文件名规则：会生成bigdata.zip、bigdata.z01、bigdata.z02这种序列。分卷压缩本质上是把一个 zip 按固定大小切片，不是每个卷独立压缩。这意味着你不能只拿一个z01文件解压，必须所有分卷齐了，放在同一个目录里，从bigdata.zip解压才行。
我在处理分卷时有几个经验：
- 分卷大小不要选得太小，比如 10MB 一卷，几百兆数据会切出几十个文件，传输和排序都很痛苦。一般选 100MB 或与传输通道限制匹配的大小。
- 接收方如果用的是较老的解压工具，分卷支持可能不完善，建议提醒对方用 7-Zip 或新版 WinRAR 操作。
- 分卷包只要缺一个卷就无法正常解压，为此我通常会在生成分卷后，额外校验每个卷的哈希值，再一起发给对方。
分卷配合前面讲的日期命名，在向客户交付大文件时非常实用，能避免单文件超限上传失败的问题。
5.2 服务器上 zip 备份与 tar 的复合用法
我在服务器上做备份时有一套自己的流程，这里分享出来供参考。核心思想是：日常轻量维护用 zip 直接交付，真正要留底的服务器备份用 tar 先做，再按需求二次处理。
# 日常交付给同事/客户，zip 一步到位 cd /var/www && zip -rq site_$(date +%Y%m%d).zip site -x "*/logs/*" # 离线冷备份，tar 保留权限，再转 zip 便于 Windows 读取 tar cf - /var/www/site -C /var/www | zip -rq backup_site_$(date +%Y%m%d).zip - -@第二条约等于从 stdin 喂文件列表，-@让 zip 从标准输入读取待打包文件的路径。这样合起来的效果是：tar 负责不带压缩地收集文件，把数据流给 zip，zip 直接压缩成 zip 包，文件权限信息由 tar 在管道中携带，但 zip 本身无法完整保留 Unix 权限位，所以这个流程其实是“tar 收拢、zip 出包”。如果目标读者是 Linux 内部使用，我建议直接用tar czvf更省事；只有要永久留存并跨平台读取的场景，才用这种复合命令。
说实话，zip 的-x参数已经能满足大部分排除需求，这个复合流程适合那种“既要 tar 的忠实度，又要 zip 的通用性”的少数需求。写在这里就当给读者一个思路拓展。
5.3 服务器环境下的权限保留与属主问题
用 zip 压缩再解压后，文件的属主、属组和权限位常常会丢失或改变，这是 zip 格式天生的短板。zip 虽然会在额外字段里记录 Unix 权限（external attributes），但解压时是否恢复，完全取决于解压工具的实现。我之前在一个项目里备份配置目录，解压后所有文件变成当前用户所有，权限也变成默认值，差点把服务搞挂。
针对这个，我有几个建议：
- 关键配置文件的备份，优先使用 tar，因为 tar 完整记录权限和属主，恢复时用
tar xpvf能还原。 - 如果必须用zip交付配置文件，建议在目标机器解压后立即执行权限修正，别让文件带着错误权限上线。
unzip -q backup_config.zip -d /opt/config chown -R www-data:www-data /opt/config chmod -R u=rwX,g=rX,o=rX /opt/config- 如果是压缩来自其他用户目录的文件，zip 会提示权限不足，此时要么用 sudo 执行压缩，要么先确认读取权限足够。
sudo压缩时生成的包内文件所有者信息可能是 root，解压的人如果不是 root，就要格外注意属主变化。
另外一个相关热词“linux提权”在多数技术讨论里指的是权限提升攻击，但是在 zip 场景下，我更想强调的是：不要用 root 身份随便压缩和解压用户目录，用普通用户操作后如果缺权限，再按最小权限原则补。避免留下一堆 root 所有、别人动不了的压缩文件，是运维的基本素养。
6. 常见问题与排查技巧实录
6.1 问题速查表
我把这些年在 zip 压缩文件夹时遇到的高频问题，整理成了速查表，方便你直接对照处理：
| 现象 | 可能原因 | 解决思路 |
|---|---|---|
| zip 包只有空目录，没有文件 | 忘记加-r参数 | 补-r重新压缩 |
| 解压后中文文件名乱码 | 编码不匹配（GBK/UTF-8） | Linux 解压用unzip -O GBK，Windows 端升级工具 |
zip命令找不到 | 系统未安装 zip | apt install zip/yum install zip/dnf install zip |
提示Permission denied | 对目录无读权限 | 检查用户权限，或改用 sudo 并注意属主变化 |
| 压缩包体积远超预期 | 包含已压缩媒体/图片，或符号链接被追踪 | 用-0，或加-y保留链接 |
| 拿到分卷包无法解压 | 缺少分卷、分卷改名、或解压工具不支持 | 集齐全部分卷，保持原文件名，用新版 7-Zip |
| 解压时一直要密码 | 真加密或伪加密标志位 | 真加密需要密码；伪加密可换工具直接剥离 |
| 包内路径带着一长串目录 | 用绝对路径压缩导致 | 先 cd 到父目录再用相对路径打包 |
| 解压后权限/属主不对 | zip 不完整保留 Unix 权限 | 用 tar 备份，或者解压后手动chown/chmod |
| 压缩大文件时 CPU 跑满但很慢 | 单线程压缩，级别高，文件本身难压缩 | 降低压缩级别、用-0，或改用 7z/pigz |
6.2 排查思路现场：一个诡异的 zip 损坏案例
有次同事发现一个 zip 备份包解压到一半就报unzip: invalid compressed data。我先按常规思路跑unzip -t，弹出 CRC 错误，定位到某个文件损坏。这个文件单独从源目录复制出来却完全正常，说明问题出在打包或传输环节。
进一步排查发现，这个包是传过三次网盘才到手的，网盘在传输中对文件做了某种分段处理，导致 zip 包中间某一段损坏。解决办法很朴素：重新用校验和验证传输文件，改用分卷压缩，避免单文件过大在网盘传输中被截断。这里我切身的体会是，zip 包损坏之后，第一时间别急着重新传输那个文件，先确认原始包在源服务器上的md5sum是否一致，不一致肯定传输有损。传输本身就是个隐藏的坑，很多人只盯着压缩命令，忽略链路可靠性。
6.3 批量压缩与并发限制的经验
服务器上经常需要批量压缩多个目录。我比较常用的是 for 循环：
cd /data for dir in projectA projectB projectC; do zip -rq "${dir}_$(date +%Y%m%d).zip" "$dir" -x "*/cache/*" done但注意，zip 本身是单线程的，for 循环也是串联执行。如果目录很多且 CPU 有富余，可以写成简单并发：
cd /data for dir in projectA projectB projectC; do zip -rq "${dir}_$(date +%Y%m%d).zip" "$dir" -x "*/cache/*" & done wait这个脚本之所以我经常用，是因为它朴素、容易理解。不过并发量要控制，建议别超过 CPU 核数。如果机器内存较小，同时压缩多个大目录可能把内存打满，我一般按 CPU 数限制并发数，并提前free -g看一眼内存。还有个小细节：并发压缩时日志会混在一起，可以在命令后面加>& 日志路径把输出分化开，方便排查。
6.4 一个长期维护项目的心得
最后想分享一个综合案例。有段时间我负责一个目录的每日归档，目录里有数据库 dump、日志、上传文件。最初我图省事，直接zip -r backup.zip /data，结果把整个目录的可能几百 GB 的 log 打进去了，每晚压缩耗时极长，还占磁盘。后来我改成这样：
cd /data zip -rq "backup_$(date +%Y%m%d).zip" . \ -x "*/log/*" -x "*/tmp/*" -x "*.cache"然后每天早上验收时，第一件事就是确认生成时间、检查包大小、跑unzip -t。后来又把保留策略加上，超过 7 天的 zip 自动删掉，才最终稳定下来。这个流程不算多高级，但胜在每一步都有验证，长期跑了几年基本没出过事故。越是基础的命令，越值得用工程化思维去对待。
如果你在一个复杂环境里工作，可能在搜索时还会看到“linux常用命令大全”“linux安装docker”之类的内容，这些虽然和 zip 没关系，但说明你大概率在系统化学习 Linux。那我的建议是在练 zip 时顺便把unzip、tar、find、xargs一起串起来练，因为实际备份脚本里它们往往是配合出场的，比如find /data -name "*.log" | xargs zip -r ...这种组合用法。工具链连成一条线，工作流才真正顺。
话说回来，zip 压缩文件夹命令本身真的不难，难的是你确切知道自己要什么格式、给谁用、在哪个平台解压、速度优先还是体积优先。把这些想清楚，命令就那几个字母的事。我花了大量篇幅讲场景和坑，是因为实际操作里天然会不断重复遇到这些细节，知道了，后面就顺了。
