前一阵子给客户迁移一套服务我把整个应用目录用 tar 打包拷到新服务器结果解压完发现一堆软链接变成了普通文件服务起不来另一处又遇到 cp -r 拷完目录后里面指向绝对路径的软链接全部失效链接还在但目标统统指向了旧机器的老地址。那会儿排查了大半天最后才意识到问题出在我根本没搞懂 tar、zip、cp 在处理符号链接时的默认行为有的命令默认保留链接有的默认跟着链接把真实文件复制走了完全相反。所以这篇就专门讲清楚一件事在 Ubuntu 上做文件压缩、解压缩、打包解包、拷贝文件、拷贝文件夹时碰到软链接到底该怎么办。命令本身不难难的是理解每个工具的默认行为和参数背后的逻辑。文章会覆盖 tar、zip、cp、rsync 这些最常见的工具给到可以直接抄作业的参数组合也会把容易踩的坑一个个列出来。适合刚接触 Linux 的新手也适合那些平时用命令很溜、但没仔细想过“链接到底怎么处理”的老手。1. 软链接为什么总在迁移时翻车1.1 软链接的本质一个存着路径的“快捷方式”软链接也就是符号链接symbolic link在 Linux 里本质是一个非常小的特殊文件文件内容就是目标路径字符串。它不包含真正的数据只记录“我指向哪里”。用ls -l看的时候权限位第一个字符是l文件大小通常就是目标路径的长度比如指向/usr/lib/libfoo.so的链接大小就是 20 字节左右。你可以把它理解成 Windows 的快捷方式但比快捷方式更底层很多系统工具、编译链接、服务配置都在依赖它。比如常见的/etc/alternatives、动态库的libfoo.so - libfoo.so.1.0、Python 虚拟环境里bin/python - /usr/bin/python3.12全是软链接。既然软链接只是“一个指向路径”那么拷贝、打包、压缩时就会面临一个核心选择你是要把这个“链接本身”搬走还是要把“链接指向的真实内容”复制一份两个需求都是合理的但工具默认行为不一样用错就翻车。1.2 带软链接操作时最常见的三种翻车场景第一种打包时用了tar -h结果链接全被“跟随”dereference成了实体文件。如果你链接指向的是一个超大文件包会突然膨胀好几倍解压出来后原来那些lrwxrwxrwx的链接全部变成了普通文件破坏了服务对目录结构的依赖。第二种cp -r拷贝整个目录表面上链接还在但如果你原来用的是绝对路径链接比如ln -s /home/ubuntu/app/lib/libfoo.so /home/ubuntu/app/bin/foo到新机器上链接字符串还是/home/ubuntu/app/...指向的却是根本不存在的旧路径。第三种用 zip 压缩目录解压后所有符号链接都变成了实体文件的副本。因为 zip 的默认行为和 tar 恰好相反它默认会把链接指向的内容打包进去而不是保存链接本身。很多人栽在这上面就是因为完全没料到 zip 会这样。1.3 动手前先问自己保留链接还是跟随链接这是整个文章最核心的一句话。操作带软链接的文件先想清楚你要“保留链接preserve symlink”还是“跟随链接dereference”。保留链接就是把链接本身原样搬运链接指向的实体文件如果不在目录树里也不会被复制进来。适合场景迁移应用的配置目录、复制依赖固定相对路径的工程目录、备份/etc这种充满链接的系统目录。因为很多链接的目标在系统里本身就存在比如/usr/bin/python3你只需要把链接从旧机器移到新机器新机器上有同样的目标文件服务就能正常跑。跟随链接则是把链接指向的真实内容复制一份原本的链接在新位置会变成普通文件。适合场景做一个“自包含”交付包把整个运行环境连带依赖的库文件全部打进去接收方解压后不依赖任何外部路径就能用或者归档数据让后续的人不关心链接这回事。目标不同命令就不同。下面的内容全是围绕这个选择展开的建议你先把这两个词刻在脑子里。2. 压缩与解压缩打包、压缩别再傻傻分不清2.1 打包是合并压缩是瘦身很多初学者会把“打包”和“压缩”混为一谈。严格说打包是把一堆文件和目录合并成一个文件比如 tar 的原始能力就是“归档”它本身并不压缩压缩是把数据的体积变小比如 gzip、bzip2、xz、zstd。平时用的tar.gz其实是先 tar 打包再用 gzip 压缩tar 只是通过-z参数自动帮你调用了 gzip。理解了这一点你就知道为什么tar -czvf里的-z可以换成-j、-J、--zstd因为只是换了个压缩器而已。而 zip 不一样它一步到位既打包又压缩内部还有自己的文件索引结构。从使用习惯上看tar 在 Linux 世界里更“正统”所有属主、权限、链接信息都能完整保留zip 则更偏向跨平台传输Windows 上双击就能解压。2.2 tar 的常见压缩参数怎么选用 tar 的时候后缀通常和参数是对应的后缀参数压缩率速度说明.tar.gz-z中等快最通用几乎所有环境都支持.tar.bz2-j较高较慢体积更小但压缩和解压都慢一些.tar.xz-J最高很慢分发源码包常用体积控制最好.tar.zst--zstd高很快新工具压缩快、体积也小但目标机器要装 zstd日常做备份、迁移、传文件我基本只用tar.gz。它速度够快兼容性最好在 Ubuntu 上开箱即用没必要为了省那点体积去等 xz 压半天。如果是给别的系统传包或者对方环境不确定更不要用 zstd万一对方机器上没有这个工具解压都成问题。顺带一提tar -tvzf file.tar.gz可以不解压直接查看包内文件列表做打包后的完整性检查非常有用。如果列表里看到权限位是lrwxrwxrwx就说明这个包保留的是软链接不是实体文件。2.3 压缩单个文件gzip、bzip2、xz 直接上如果只是压缩单个文件不涉及目录和链接那就直接用压缩器本身。比如gzip app.log bzip2 app.log xz app.log注意这些命令默认会直接删掉原文件只留下压缩后的文件。不想删原文件就要加-k比如gzip -k app.log。解压则是对应gunzip、bunzip2、unxz同样默认删掉压缩包。单个文件的压缩很少会遇到软链接问题因为命令行的链接参数一般会被跟随压缩的是链接指向的目标内容解压出来是一个普通文件。如果非要保留链接本身那就不要用 gzip 家族直接用cp -P或 tar 打包更合适。2.4 zip 的默认行为是反直觉的别踩坑zip 在 Ubuntu 上也很常用但它的默认行为和 tar 正好相反。tar 默认保留软链接zip 默认跟随链接把真实文件压缩进去。什么意思你压缩一个包含软链接的目录zip -r backup.zip mydir解压后原来的软链接libfoo.so - libfoo.so.1.0会直接变成一个完整的实体文件libfoo.so内容就是libfoo.so.1.0的副本。如果链接指向的文件很大整个 zip 包会莫名变大。要保留软链接本身必须加-yzip -ry backup.zip mydir-y的意思是把符号链接作为符号链接存储解压时还你一个链接。这个参数很多人不知道但只要你处理带链接的目录就一定要记得加。另外如果解压方是在 Windows 上对符号链接的支持可能很弱建议跨平台传输时还是老老实实用 tar.gz。2.5 解压时注意目标目录和权限解压命令本身很简单但有几个容易忽略的点。一个是-C指定解压目录比如解压到指定目录tar -xzvf backup.tar.gz -C /tmp/restore unzip backup.zip -d /tmp/restore另一个是权限问题。如果是 root 用户解压 tar 包默认会尽量恢复包内记录的属主和权限如果是普通用户解压则不管包内记录的属主是谁解压出来的文件都会归当前用户所有权限也会按当前 umask 重新计算。这在你从服务器上备份配置到本地电脑时特别明显解压完一堆文件属主变成你自己这是正常的。还有一点tar 解压带 ACL、扩展属性比如 SELinux 上下文、capabilities的文件时普通参数不会保留这些元数据。需要的话要加tar --xattrs --acls -xzvf backup.tar.gz不过大多数普通项目用不到知道有这回事就行。3. 打包与解包tar 正确处理软链接的关键3.1 默认行为tar 会保留软链接tar 的默认行为是保留软链接这是它作为“归档工具”的核心设计理念之一把目录树的原样搬走。当你执行tar -czvf backup.tar.gz /home/ubuntu/app这个包里的软链接会被记录成“这是一个符号链接目标是 xxx”。解压时tar 会重新创建链接而不是复制链接指向的文件。验证方法很简单打包后看包内文件列表tar -tvzf backup.tar.gz | grep -如果输出里有类似lrwxrwxrwx的行比如lrwxrwxrwx root/root 11 2025-01-01 10:00 home/ubuntu/app/lib/libfoo.so - libfoo.so.1.0说明链接被完整保留了。注意那个大小是 11 字节对应libfoo.so.1.0这个路径字符串的长度而不是实体文件的大小。如果这里显示的体积和实体文件一致说明链接被跟成了实体那就要警觉。3.2 真正危险的是随手加 -h 或 --dereferencetar 的-h/--dereference参数作用恰好和默认行为相反它会让 tar 在打包时“跟随”符号链接读取链接指向的真实文件内容把真实内容打包进去。解压出来以后原来的链接就变成了实体文件。有人可能觉得“既然链接是快捷方式那我加 -h 把内容打进去更保险”这恰恰是迁移服务时最致命的错误。因为很多服务的配置目录里链接指向的目标是系统路径比如/usr/lib/...用 -h 打包会把整个/usr底下的库文件也拉进包里包体积瞬间爆炸解压到新机器后目录结构还和原来不一致服务反而起不来。那什么时候确实要用 -h典型场景是你想把整个运行环境做成自包含的包链接指向的实体文件也必须一并带走。比如一个 Python 虚拟环境里的bin/python - /usr/bin/python3.12如果目标机器没有 Python 3.12你就得用 -h 把真实二进制打进去解压后直接可用。用的时候心里要有数-h不只是“处理链接”的意思而是“把链接指向的东西全给我掏出来”。如果链接指向一个 2GB 的数据库文件用 -h 打包后你会得到一个 2GB 的 tar 包而默认打包可能只有几 MB。3.3 解包后链接失效的排查与修复链接失效有两种典型情况。第一种是链接还在但指向的目标在这个机器上不存在这就是死链dangling symlink。第二种是链接被拷贝成了实体文件失去了链接属性。排查死链最直接的方法ls -l 目录/看链接后面是否带-以及目标是否真实存在。如果链接太多可以用 find 批量找出来find /home/ubuntu/app -type l ! -exec test -e {} \; -print这个命令会列出所有“存在但目标不存在”的软链接。注意文件名里如果有空格建议换成-print0的写法配合xargs -0处理。如果是绝对路径链接失效比如旧机器上链接指向/opt/app/lib/libfoo.so新机器路径变成了/data/app/lib/libfoo.so那就要批量重建。一个保守的脚本思路是把绝对路径映射到新路径find /data/app -type l | while IFS read -r ln; do t$(readlink $ln) case $t in /opt/app/*) new_t/data/app/${t#/opt/app/} ln -sfn $new_t $ln echo fixed: $ln - $new_t ;; esac done这个脚本是把以/opt/app/开头的链接目标全部改成/data/app/下对应位置。ln -sfn里的-n很重要它防止目标路径恰好是一个目录时把链接建到目录里面去。脚本本身仅供参考真实环境一定要先打印、确认、再执行不要上来就批量改。还有一种更优雅的解决方案在源机器上就尽量使用相对链接。相对链接只记录相对位置比如../lib/libfoo.so.1.0只要目录树的相对结构不变搬到任何路径下都能正常工作。所以如果你能控制链接的创建方式尽量用相对路径建链接迁移成本会小很多。3.4 跨机器迁移的顺手姿势tar 管道和 rsync跨机器迁移时不一定非要先打包再拷贝到一个中间文件。如果你能直接 SSH 到目标机器可以用管道直接把 tar 流送过去tar -C /home/ubuntu/app -czf - . | ssh usernew-server tar -C /data/app -xzf --C先进入源目录再打包避免包内路径多一层-f -表示输出到标准输出SSH 那头再解压。好处是省了一次中间文件传输坏处是网络中断就全断了只适合网络稳定、目录不大的场景。另一个强烈推荐的工具是 rsync。它对软链接的处理也很明确-a参数默认保留软链接、权限、时间戳等rsync -av /home/ubuntu/app/ usernew-server:/data/app/注意源目录末尾的斜杠代表“目录内容”而不带斜杠会同步整个目录本身。rsync 还有个好处是可以增量同步第一次全量后面每次只传变化的部分。对反复部署、同步来说比 tar 打包再传输实用太多。4. 拷贝文件、拷贝文件夹cp 命令的参数矩阵4.1 单文件拷贝默认是跟随链接的这是最容易忽略的一个点。当你直接拷贝一个软链接文件cp libfoo.so /tmp/libfoo_copy.so结果不是把libfoo.so这个链接拷过去而是把libfoo.so指向的真实文件内容复制了一份得到的是普通文件。换句话说cp 对命令行上直接给出的软链接默认是跟随的。如果你想把链接本身拷贝过去目标是再得到一个链接需要加-P或者-dcp -P libfoo.so /tmp/libfoo_copy.so cp -d libfoo.so /tmp/libfoo_copy.so-d其实是一个组合参数等价于--no-dereference --preservelinks也就是说不仅不跟随链接还会尽量保留硬链接关系。拷贝单个文件、明确要保留链接时用-d最省心。4.2 cp -r 的行为顶层跟随目录内部保留cp -r src dst这种递归拷贝目录的写法大家用得很多但它的软链接行为比较微妙。GNU cp 的规则是如果命令行的源参数本身就是软链接默认会跟随它、复制真实内容但在递归目录的内部遇到的软链接默认会保留为链接本身。举个例子你执行cp -r /home/ubuntu/app /tmp/app_backup如果/home/ubuntu/app本身是链接那cp -r会把它当普通目录处理复制里面的内容到目标如果/home/ubuntu/app里面的bin/foo是软链接则bin/foo会被保留成软链接。但这里有个容易踩的细节如果你把app整个目录搬到一个和原来完全没有关系的位置里面那些相对链接一般没问题因为它们记录的是相对关系绝对链接就基本全部失效还是要靠重建或者改用相对链接。为了避免纠结我的建议是拷贝目录并保持原样直接无脑用cp -acp -a /home/ubuntu/app /tmp/app_backup-a等价于-dR --preserveall意思很直白递归复制保留链接、权限、时间戳、属主、ACL 等所有能保留的属性。它几乎就是“复制目录树”的终极答案几乎所有 Linux 发行版上都能用。那如果你就是想跟随链接把整个目录树变成实体副本呢用cp -Lcp -aL /home/ubuntu/app /tmp/app_selfcontained-L表示跟随所有符号链接复制真实内容和-a组合既保留文件属性又把链接全部“解引用”。这个命令很适合制作自包含的交付目录。4.3 拷贝文件夹场景建议实际使用中我建议你把cp -a当成拷贝目录的默认选项而不要用裸的cp -r。为什么因为-a还帮你保留了时间戳和属主后期排查文件新旧、确认权限时省很多事。备份场景推荐这种写法cp -a /srv/app /backup/app_$(date %F)如果目录里含软链接先看一下统计再动手find /srv/app -type l | wc -l如果链接很多拷贝完成后再验证一次有没有死链find /backup/app_$(date %F) -type l ! -exec test -e {} \; -print另外使用cp -L或cp -aL前一定要先看看链接指向的文件有多大。可以用这个命令估算如果跟随所有链接实际要复制多大体积du -shL /srv/app如果这个数字比du -sh /srv/app大得多说明链接指向了许多外部的大文件盲目cp -L可能瞬间吃掉磁盘空间。5. 常见报错与排查技巧实录5.1 常见问题速查表现象原因解决方法tar 解压后原来链接变成了普通文件打包时加了-h或--dereference去掉-h用默认打包zip 解压后链接全部变成实体文件zip 默认跟随链接压缩时加-ycp单个文件后链接变普通文件cp 默认跟随链接使用cp -P或cp -dcp -r后目录内绝对路径链接失效链接目标路径在新机器不存在改为相对链接或重建链接解压时报Operation not permitted目标文件系统不支持符号链接先解压到本地磁盘再同步报Too many levels of symbolic links链接链形成循环或无限递归用readlink定位重建链接拷贝后权限、属主变了没有用cp -a或 tar 缺少--xattrs用cp -a保留属性tar 解压后属主全是当前用户非 root 解压需要 root 权限才能保留原属主5.2 Too many levels of symbolic links 的含义这个报错本质是系统发现你访问一个链接时目标本身又是链接反复追下去追不到底达到了内核设置的最大跟随层级。最常见的原因是你自己建了一个“自杀链接”ln -s a a或者链接指向一个包含自身的路径形成了循环。排查思路很简单先找到报错路径然后用readlink一层层看目标readlink a ls -l a如果是死循环直接把出问题的链接删掉重建即可。这里只有一个忠告在没有确认之前不要对看似可疑的目录执行rm -rf先ls -l看清楚链接指向哪里再用rm删链接文件本身。5.3 拷完链接变普通文件怎么办这种情况高发于用了cp默认参数、zip 不加-y、或者 tar 打包加了-h。判断方法file /tmp/app/lib/libfoo.so如果输出是ELF shared object或ASCII text之类说明它是普通文件如果输出是symbolic link to libfoo.so.1.0说明还是链接。如果是普通文件但你想恢复成链接操作分两步先删掉这个实体副本再重建链接。注意删之前确认目录里没有其他文件依赖这个实体文件的内容rm /tmp/app/lib/libfoo.so ln -s libfoo.so.1.0 /tmp/app/lib/libfoo.so清理这种问题最怕的就是“看起来是文件其实是链接”和“看起来是链接其实是文件”两种情况同时存在所以复制完目录以后我强烈建议先用find -type l检查一遍所有链接确保结构和预期一致。5.4 虚拟机共享目录和其他文件系统限制很多人在 Ubuntu 虚拟机里开发文件放在 VirtualBox 的共享目录里这时候解压带符号链接的包很容易报Operation not permitted因为 vboxsf 这类共享文件系统对符号链接的支持通常受限普通用户根本创建不了链接。解决办法很直白先在本地磁盘路径解压比如~/tmp或者/tmp再把内容拷贝或同步到共享目录。如果同步也报错那基本是共享目录本身不支持建议把最终交付目录放在虚拟机磁盘里不要放在共享文件夹里。另外一个和链接相关的限制是硬链接不能跨文件系统。比如你在/home一个分区和/data另一个分区之间做cp -a硬链接关系可能会丢因为目标文件系统里的 inode 是全新的。软链接没有这个问题它只是一个路径字符串。6. 我现在固定用的流程踩过这么多坑之后我现在的习惯非常固定也分享给你参考。第一步永远先摸底看目录里有多少软链接哪些是绝对路径哪些是相对路径有个大概印象再动手find /srv/app -type l | wc -l find /srv/app -type l -exec ls -l {} \; | head -20第二步明确意图。如果只是迁移配置、同步代码默认保留链接用tar -czvf或rsync -av如果要交一个自包含包才用tar -chzvf或cp -aL并且先du -shL确认体积。第三步操作完必须验证链接状态。tar 包用tar -tvzf | grep -看链接是否原样存在目录拷贝后跑一遍死链检查确认find -type l ! -exec test -e {} \; -print没有输出。第四步才是启动服务。链接这种东西最怕的就是你以为搬完了、其实搬的是个空壳。所以在真正切流量之前花两分钟检查一下能省掉后面一整夜的排查时间。说到底处理软链接的难点从来不在命令本身而在理解每个工具的默认倾向。tar 默认保留链接zip 默认跟随链接cp 默认跟随命令行链接但保留目录内部链接rsync 默认保留链接。你只要把每个工具的默认行为记清楚再对照“保留还是跟随”这一条原则就不会再被软链接坑得团团转了。