如果你经常用cp拷贝大文件，或者用mv搬迁数据目录，大概率有过这种体验：命令敲下去，屏幕安静得像什么事都没发生，只有光标在闪。文件多大、传输速度多少、还要等多久，一概不知。尤其在服务器上操作几十 GB 的数据，盯着屏幕却不知道进度，那种感觉相当难受。今天聊的内容就是把 Linux 下最常用的cp、mv命令加上进度条，让拷贝过程从“盲切”变成“可视”。
这篇内容适合所有 Linux 用户，无论你是刚接触命令行的新手，还是每天跟服务器打交道的运维、开发。我会讲清楚背后的原理、两条主流的实现路线、编译补丁的具体操作，以及我实际使用中踩过的坑和最终的习习惯用法。保证你看完不是只会跑一条命令，而是明白为什么这样做、换一台机器也能自己搞定。
1. 先说痛点：cp/mv 的命令行为什么这么“闷”
1.1 原生命令的“静默工作法”，以及它带来的现实困扰
cp和mv是 Linux 里最古老、最基础的两个文件操作命令。它们的原始设计目标就是“简单、可靠、尽量少的输出”。Unix 哲学里有一条就是“没有消息就是好消息”，所以默认情况下，cp和mv都不会给你任何进度反馈。它们把心思放在“只要不出错，就别打扰用户”上。
这种设计在终端里处理少量文件时没什么问题，但一旦碰上大文件、大目录，问题就来了。拷贝 2 GB 的数据库备份文件，敲完cp之后，你的选择只有等，不停地等。要么用另一个终端反复ls -l看文件大小有没有变化，要么开个top看进程状态，要么就干瞪眼。要是传的是一整个应用目录，里面有几千个小文件，你甚至连文件大小都不好判断，只能凭经验猜。
更让人抓狂的是，cp拷贝过程中如果磁盘写满、网络断掉或者源文件出问题，你往往要等很久才能发现。相比可视化界面的文件管理器，命令行在这种场景下简直像睁眼瞎。所以给cp、mv加进度条，本质上不是炫技，而是解决一个非常实际的“信息缺失”问题：它让你知道数据到底在不在流动、走了多少、还剩多少。
1.2 两条改造思路：是换工具，还是给原命令打补丁
想给cp、mv加进度条，思路主要分两条线。
第一条线是“换工具”。直接用rsync、pv这类本身支持进度显示的命令来替代。比如rsync -av --progress能做带目录递归、断点续传、速度显示的拷贝，pv可以放在管道中间显示流式的进度。这条路的好处是几乎不用编译任何东西，主流发行版装一下就有；坏处是它们的行为和cp、mv并不完全一致，比如rsync默认会校验元数据、有自己的增量同步逻辑，直接用rsync替代mv更是不伦不类。
第二条线是“给原命令打补丁”。GNU coreutils 是 Linux 上cp、mv、ls等基础命令的来源，有人专门给 coreutils 做了一个补丁，让cp、mv获得-g参数，开启进度条。这就是很多教程里提到的advcpmv。这条路的核心逻辑是：用打了补丁的 coreutils 替换系统自带的cp、mv，或者更稳妥地以包装函数的方式让cp、mv在命令行里自动映射到新版本。
这两条路我都实际跑过。结论是：日常命令行交互，打补丁方案最顺手，因为cp、mv的参数和习惯完全不变，只是多了进度显示；自动化脚本、备份任务这种场景，我反而更推荐rsync，因为它的日志、退出码、断点能力更成熟。后面我会把两条路的具体操作和取舍都写清楚。
1.3 一个重要的前提：mv 和 cp 的进度逻辑差别
很多人以为给mv加进度条和cp一样，直接怼上同一个参数就行。实际没那么简单。mv在同一个文件系统内移动文件时，本质只是修改目录项，数据根本没搬动，所以瞬间完成，自然也没有进度可言。只有跨文件系统（比如从/home往挂载的硬盘分区移动）的时候，mv才会退化成“先复制、再删除”的过程，这时候才有进度显示的价值。
所以你在用带进度条的mv时，如果发现它秒完了，先别怀疑是不是补丁没生效。先确认源路径和目标路径是不是在同一个文件系统内，用df看一下两个路径挂在哪个分区下就清楚了。如果都在同一块盘上，mv再怎么打补丁也不会给出令人激动的进度条。
cp则不同，只要不是写进页缓存以后瞬间完成的小文件，它总会有一个真实的数据复制过程。所以进度条在cp身上的实际价值远高于mv。这一点也直接影响后面我们对包装脚本的设计思路：我建议把mv的进度条参数做成只在跨文件系统时自动附加，而不是永远无脑开启。
2. 方案横向对比：advcpmv、rsync、pv、以及自定义函数
2.1 advcpmv：给 coreutils 打补丁，直接获得 -g 参数
advcpmv不是一个独立软件，而是一组补丁，用于修改 GNU coreutils 源码，最终让cp和mv支持进度条显示。补丁作者通过给源码里的复制逻辑插入一个“进度观察器”，让cp、mv在复制数据时定期统计已经读写的字节数、计算出速率、剩余时间，然后输出到终端。
装上之后，你会得到一个带-g参数的cp和mv。执行cp -g bigfile.img /data/时，终端底部会实时刷新一行信息，看起来像这样：
0.1 GiB / 2.0 GiB [===>________________] 5.2% Rate: 45.6 MiB/s | ETA: 00:42这行信息里有当前进度、总体进度条、瞬时速率、预计剩余时间，基本把用户关心的点都覆盖了。而且它用的是终端控制字符原位刷新，不是一行行刷屏，观感很干净。
它的最大优点是兼容性：因为本质上还是标准 coreutils 的cp、mv，所有原生命令参数都保留。你不需要重新记忆另一套工具，也不用担心--preserve、-a、-u这类高级参数失效。缺点就是需要自己动手编译，而且补丁跟随 coreutils 版本迭代，换一个发行版大版本之后可能要重新编译适配。
2.2 rsync：不用编译，但行为不等于 cp/mv
rsync是另一条非常高性价比的路线。它的--progress参数能显示每个文件的进度百分比，--info=progress2能显示总体进度，而且支持中断后重新传输时跳过已有数据，这个能力是cp永远比不了的。
实际用的时候，一条典型的拷贝命令是这样：
rsync -ah --info=progress2 /home/user/data/ /mnt/backup/data/-a是归档模式，保留权限、时间戳、软链接；-h把速度显示成易读的单位；--info=progress2输出总任务的总体进度。如果你备份的是超大目录，还能加上--partial --append-verify实现断点续传。
但是要注意，rsync不是cp的完全替代品。它的默认逻辑是增量同步，会扫描源目录和目标目录的差异，文件很多的时候，光是扫描阶段就要跑一会儿。另外rsync的--delete、排除规则等参数，如果用习惯了会很好用，但如果只想“拷贝，别玩花的”，反而会觉得它太重。
所以我的判断是：临时拷单个大文件、或者你在命令行交互时想要最接近cp的体验，选advcpmv；做备份、同步目录、定期任务，用rsync才是标准答案。
2.3 pv 管道方案：适合单个文件与流式场景
pv（Pipe Viewer）是另一个被很多人安利的工具。它不直接替换cp、mv，而是坐在管道中间，监视流经它的数据量。经典用法是这样：
pv bigfile.iso > /dev/null或者把文件和dd配合：
pv bigfile.iso | dd of=/dev/sdb bs=4M这种方案的好处是通用性极强，任何管道里的数据流都能被它监控。缺点也明显：你没法用它直接复制目录树、保留权限，它只是“给数据流装上流量表”。
对我来说，pv更适合临时观察“某个压缩工具到底有没有在干活”的场景，比如tar打包一个超大目录时，用pv接到tar的输出管道上，能看到打包进度。但这不是主题里的cp、mv替换方案，只作为补充提一下。
2.4 用 Shell 脚本自己模拟进度条的代价
还有一种思路是写一个 Shell 循环，反复检查目标文件大小，然后自己算百分比和速度，再输出。这种方案看起来自由，实际很坑。因为你需要定期执行stat获取文件大小，循环本身会消耗 CPU；而且 Shell 循环里做浮点运算、控制刷新频率，都会让脚本变得复杂。更重要的是，cp对目标文件的写入方式是随机的，你通过stat看到的文件大小不一定线性增长，遇到先写稀疏块后填充数据的场景，进度会跳变得很厉害。
我自己早年也折腾过这种脚本，最终放弃了。结论就是：这种“伪进度条”可以在小工具里玩玩，但真正大规模的拷贝场景，它的可靠性和可维护性都远不如上面三个方案。如果你想给cp、mv做一个长期可用的进度条，老老实实选advcpmv或者rsync。
3. 实操：编译 advcpmv 的核心步骤与参数选择
3.1 环境准备，以及为什么建议先编译到源码目录而不是覆盖系统
既然确定了打补丁这条路，接下来就是动手。先强调一个经验：千万别上来就把编译出来的cp覆盖到/usr/bin/cp。系统很多脚本和管理工具内部依赖cp、mv，如果你替换的版本有奇怪的问题，系统可能会出各种幺蛾子。安全做法是编译到自定义目录，比如/usr/local/bin或~/software/coreutils/bin，然后用 PATH 或包装函数的优先级让用户命令先找到它。
实际操作里，我习惯把编译结果放在/usr/local/bin下面。因为这个目录在多数 Linux 发行版中的优先级本身就比/usr/bin高，普通用户执行cp时，Shell 会先找到/usr/local/bin/cp。同时系统内部的一些 service 脚本多数使用绝对路径/bin/cp调用，所以不会受影响，两全其美。
在环境准备上，你需要安装编译工具链：gcc、make、autoconf、automake等。在自己电脑上建议直接用发行版包管理器安装。比如 Debian/Ubuntu 跑sudo apt install build-essential autoconf automake，CentOS/RHEL 跑sudo yum groupinstall "Development Tools"。如果你用的是国产 Linux 发行版，比如统信 UOS、麒麟，它们的包管理一般也兼容 Debian 系或 RPM 系，照着对应系统的命令装就行。
3.2 打补丁、配置、编译的具体命令
下面用当前常见的 coreutils 9.x 版本举例。步骤大致是：下载源码包、解压、进入目录、把advcpmv的补丁打进去、配置、编译。
wget https://ftp.gnu.org/gnu/coreutils/coreutils-9.4.tar.xz tar -xf coreutils-9.4.tar.xz cd coreutils-9.4/然后下载适配这个版本的补丁。advcpmv的补丁在 GitHub 上可以找到，文件一般叫advcpmv-9.4.patch。打补丁：
patch -p1 -i advcpmv-9.4.patch补丁打完之后，重新生成构建配置：
autoreconf -fiv ./configure --prefix=/usr/local make -j$(nproc)-j参数表示用多核并行编译，$(nproc)会读取你的 CPU 核心数。如果机器核数多，这一步会快很多，耐心等几分钟就好。
编译完成后，先不要急着安装。进入src目录，你会看到编译好的cp和mv两个可执行文件。可以先直接运行一下测试：
cd src ./cp --version ./cp -g 1G_file /tmp/看到进度条刷起来，再执行安装：
sudo make install安装完成后，/usr/local/bin/cp和/usr/local/bin/mv就都支持-g了。运行which cp，如果显示/usr/local/bin/cp，说明优先级已经生效。
这里有个容易踩的坑：如果你的PATH环境变量里/usr/bin排在/usr/local/bin前面，那么你敲cp时还是会命中系统原版。用which cp确认一下，如果发现不对，要么把/usr/local/bin在PATH里的位置往前调，要么像下一节说的那样，用 Shell 包装函数强制指定。
3.3 把包装函数写进 ~/.bashrc，让日常命令无缝替换
编译安装虽然完成了，但我依然不建议直接用/usr/local/bin/cp去“覆盖”你的使用习惯。更稳妥的方案是在~/.bashrc里加两个 Shell 函数，让交互终端里的cp、mv默认带上-g，同时保留对系统原版的随时访问能力。
以 bash 为例，在~/.bashrc末尾加入：
cp() { if [ -t 1 ]; then /usr/local/bin/cp -g "$@" else /usr/local/bin/cp "$@" fi } mv() { if [ -t 1 ]; then /usr/local/bin/mv -g "$@" else /usr/local/bin/mv "$@" fi }这段逻辑的重点是[ -t 1 ]判断：它检测当前命令的标准输出是不是一个终端（TTY）。如果是，说明你是手动敲命令，可以加-g看进度；如果不是，比如被脚本、cron 调用，或者输出被重定向到文件了，就不加-g，避免把进度条控制字符写进日志里产生一堆乱码。
写完保存后，执行source ~/.bashrc让配置生效。之后你敲cp、mv时，终端里自然就会看到进度条。如果哪次你确实想用不带进度条的原版命令，可以手动调用/usr/bin/cp或者先unalias cp，再包装函数的场景下可以直接用\cp来转义调用原生命令。
这里要说一下为什么用函数而不是 alias。alias 的展开原理是把命令直接替换成另一串文本，处理带参数的情况没问题，但你在函数体里想加“条件判断”的时候，alias 就不够用了。Shell 函数可以执行完整的逻辑，比如检测-t、检测是否有-g参数，这比 alias 灵活得多。
3.4 理解 -g 进度参数的格式、输出位置与 mv 的特殊参数
-g参数本身没有额外的取值，它是一个开关。具体显示格式由编译时的默认样式决定，但它会附着在标准错误输出（stderr）上，而不影响标准输出。这个细节很重要：如果脚本里把标准输出重定向到了文件，进度条乱码不会混入结果；但如果标准错误也重定向了，进度条就会一起进日志。所以前面那个[ -t 1 ]判断并不完全保险，更严谨的脚本应该判断[ -t 2 ]，检测标准错误是不是终端。
实际的进度显示大概长这样：
1.2 GiB / 8.0 GiB [##########_____________] 15.0% Rate: 102.3 MiB/s | ETA: 01:08如果你用mv又在同一文件系统内移动，这个进度条可能闪一下就结束。比如mv /home/a.txt /home/b.txt，都是家目录同一分区内，文件名改了而已，根本没有数据搬运，进度条直接从 100% 开始。跨分区移动时才有实际意义，比如mv /home/a.txt /mnt/data/a.txt，这时候你就能看到完整的进度。
另外，-g参数可以和cp的常用参数组合，比如cp -g -r large_dir /backup/、cp -g -a /data/app /mnt/backup/app。它不会干扰原生的-r、-a、-p等逻辑，这也是我推荐这个方案的最重要原因。
4. 坑与排查实录：用进度条后踩过的几个典型问题
4.1 为什么 alias 在脚本里不生效，以及 eval 函数的取舍
我最早用advcpmv时，图省事直接在~/.bashrc里写：
alias cp='/usr/local/bin/cp -g' alias mv='/usr/local/bin/mv -g'这个写法在交互终端里很好用，敲cp就自动带进度。但后来写自动化脚本时发现一个问题：脚本里明明写了cp，执行时却没有进度条，甚至在某些环境里直接报错。原因有两层：
第一，非交互 Shell（比如脚本执行）默认不会读取~/.bashrc。它读取的是~/.bash_profile或~/.profile，除非脚本里显式source，否则你的 alias 根本不存在。第二，即便你把 alias 写到~/.bash_profile里，脚本里面默认也是关闭 alias 展开的，这是 POSIX 规范要求的非交互 Shell 行为，防止脚本里的命令被别名干扰。
所以正确的做法就是我上一节提到的：用 Shell 函数，并且函数定义放到/etc/bashrc或/etc/profile.d/下，确保非交互登录 Shell 也能加载。如果你的脚本确实需要调用带进度条的版本，可以直接在脚本里写/usr/local/bin/cp -g，而不是依赖cp这个名字。
顺带说一个更“黑科技”的写法，有些人会用eval动态拼接命令：
eval "$(cat /usr/local/bin/cp) -g ..."我觉得完全没必要。Shell 函数已经足够解决 99% 的需求，动eval只会增加调试难度。
4.2 进度条在高频小文件场景下的性能回退
advcpmv的进度条机制是定期向终端输出刷新信息。对于大文件，这个刷新完全不是问题；但如果你的拷贝任务里包含海量小文件，比如一个 Git 仓库、一个 node_modules 目录，那么进度显示本身的输出操作反而会造成明显的性能回退。
我做过一个比较粗糙的实测：用系统原版cp -r拷贝一个有 10 万个文件的目录，耗时大约 30 秒；用带-g的版本，耗时可能变成 35 秒甚至更长。原因在于每一个文件完成后，进度条都要计算一次整体比例、刷新一次终端，频繁的终端写操作比单纯的磁盘复制要慢得多。
这个问题的解决方案很简单：不是所有场景都需要进度条。批量小文件时，开-g反而添乱，因为进度条刷得太快，你根本看不清内容，还白白损失性能。我个人的习惯是：拷贝单一大文件或少量大文件时开-g；拷贝海量小文件时直接不带-g。所以包装函数里可以加上一个“参数侦察”，如果命令自带-r并且目标目录预计包含大量小文件，可以手动开关。
“预计包含大量小文件”这个条件没法完全自动判断，所以我退一步的方案是：给函数加一个快捷开关，比如通过环境变量CP_PROGRESS来控制：
cp() { if [ -t 1 ] && [ "${CP_PROGRESS:-1}" = "1" ]; then /usr/local/bin/cp -g "$@" else /usr/local/bin/cp "$@" fi }当我要执行高密度小文件拷贝时，在命令前加CP_PROGRESS=0 cp -r src dst就能临时关闭进度条，不用改任何配置。这个习惯我一直保留着。
4.3 rsync 断点续传和 cp 进度条的组合使用体验
进度条帮我解决了很多问题，但也暴露了一个天然缺陷：cp一旦中断，就得从头再来。尤其是拷贝几百 GB 的数据库冷备文件时，断一次电、网线掉一次，你就要哭着重新开始。这个场景我用rsync组合弥补。
我的组合方式是：小的、单次的拷贝用cp -g，追求操作直观；大的、需要反复同步的备份任务用rsync --info=progress2。如果文件已经用cp -g拷贝了一半，结果中断了，我不会继续死磕cp，而是直接切到rsync做续传：
rsync -ah --partial --append-verify --progress /data/backup/bigfile /mnt/remote/--partial表示保留不完整的文件，--append-verify会在已有数据的基础上追加校验续传。这样原先cp -g拷贝出来的那一半数据也能被利用，不用重新下载。两个工具组合使用，既有cp的轻量直观，又有rsync的可靠续传。
4.4 终端宽度的适配问题，以及非 TTY 场景下如何规避乱码
进度条的输出会尝试填充终端宽度，但在某些窄终端或者通过tmux、screen分屏的场景下，容易出现折行或显示挤压。advcpmv会动态读取终端宽度，如果宽度太窄，比如只有 80 列，进度条会把百分比缩得很小，或者速率信息被挤到下一行。
解决办法有两个思路：一是把终端窗口拉宽，这听起来像废话，但限制你发现自己分屏宽度不到 100 列的时，进度条确实很难看；二是对于tmux用户，建议把 pane 最小宽度设置大一点，比如在~/.tmux.conf里设置set -g min-width 120。
另外，非 TTY 场景的乱码问题值得再强调一下。如果你把命令放进 cron 任务，或者用nohup cp -g ... > /tmp/cp.log 2>&1这样写日志，日志里会混入大量的 ANSI 控制字符和\r回车符，打开日志文件就是一堆[1A[2K之类的转义序列。我后来在处理日志时写了一个过滤：
sed -r 's/\x1B\[[0-9;]*[a-zA-Z]//g' /tmp/cp.log这条命令会把 ANSI 转义序列剥掉。但更干净的做法是前面说的，非 TTY 场景不要开-g。这也是我喜欢用包装函数的原因之一：它能在终端外自动剥掉进度参数，不给你挖坑。
5. 我用下来的整体体会与一点额外建议
5.1 把进度条封装成“日常默认”后的真实工作流变化
说实话，加了进度条之后，我的命令行操作风格变了不少。以前拷贝大文件，我总会顺手再开一个终端，用watch -n 5 ls -lh分阶段看文件大小增长。现在直接用cp -g，一眼就能看到速率和 ETA，不会再反复横跳。因为“剩余时间”这个信息特别关键，它能帮我在等待时做出更好的安排：ETA 只有两分钟，我就站着等；ETA 是半小时，我先把其他任务做了，再回来处理后续步骤。这种对时间的掌控感，是原生命令完全给不了的。
还有一个细节是，有了 ETA 之后，我对“传大文件”的焦虑感降低了很多。服务器上经常要跨机拷贝模型文件、日志压缩包，以前只能凭经验估；现在看到Rate: 110 MiB/s | ETA: 00:15，心里踏实得很。
5.2 如果不想碰编译，可以直接选择的几个发行方案
如果你确实不想编译，只想直接用，也有几条省事的路径。
第一条是很多二进制包管理器提供的预编译版advcpmv。比如在 GitHub Actions 或一些发行版的非官方仓库里，能直接下载打了补丁的静态编译版本。但要注意版本匹配和信任问题，尽量选择官方或高星仓库发布的二进制。
第二条是借助rsync加别名。如果你不追求cp完全一致的体验，可以用 Shell 函数把cpx定义成：
cpx() { rsync -ah --info=progress2 "$@" }以后再敲cpx就相当于带进度条的增强拷贝。它的行为更接近同步而非单纯的复制，所以适合大多数备份场景。
第三条是从头到尾使用图形化文件管理器自带的信息，但这显然不符合命令行工作流，不做专门推荐。
我自己的最终环境里，advcpmv编译出来的/usr/local/bin/cp和/usr/local/bin/mv一直保留着，配合~/.bashrc里的包装函数，交互终端里默认有进度条，脚本执行时自动剥离。这个状态已经稳定用了一年多，中间没出过需要回退的问题。如果你也经常被“拷贝不知道进度”困扰，不妨照着上面的步骤试一次，编译第一次可能花十分钟，但之后每次拷贝大文件，都会觉得这十分钟花得值。
