“command not found”错误几乎一定不是因mv未安装，而是path被清空/覆盖、运行于极简容器或 recovery 模式、或存在拼写/大小写/别名错误；验证可用type mv或command -v mv。
mv 不需要安装 —— 它是几乎所有 Linux 发行版（包括 Ubuntu、CentOS、Debian、Alpine）默认自带的 GNU coreutils 工具之一。只要能打开终端，mv 就可用。
为什么执行 mv 时提示 “command not found”？
这几乎一定不是因为没装 mv，而是以下几种真实原因：
- 当前 shell 环境的
$PATH被意外清空或覆盖（比如在自定义脚本里写了PATH=） - 你正在一个极简容器（如某些 scratch 镜像）或 recovery 模式下，确实没包含 coreutils
- 误打了别名或拼写错误，比如输入了
m v、mvv或MV（Linux 区分大小写）
验证方式：运行 type mv 或 command -v mv。如果返回 mv is /usr/bin/mv，说明它就在那儿；如果报错，再查 $PATH 或换基础镜像。
mv 重命名文件时最常踩的三个坑
重命名本质就是「同一目录下移动」，但行为受目标是否存在、是否为目录、选项是否冲突影响极大：
- 把
mv old.txt new.txt写成mv old.txt new.txt/（末尾多斜杠）→ 报错target ‘new.txt/’ is not a directory，因为mv会把带斜杠的当目录看 - 目标名恰好是个已存在的目录（比如
mv data.log logs，而logs是个目录）→data.log会被移进该目录，而不是重命名为logs；想强制重命名必须加-T选项：mv -T data.log logs - 用通配符批量操作时没引号：
mv *.log backup/没问题，但mv *.log backup（没斜杠）→ 如果backup存在且是文件，就覆盖；如果不存在，就重命名最后一个匹配的.log文件为backup，其余报错
安全重命名的推荐做法
日常使用建议始终带上 -i（交互）或 -n（不覆盖），尤其在脚本或远程操作中：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 防覆盖：用
mv -i source.txt dest.txt，遇到同名会停住问mv: overwrite 'dest.txt'? - 防误操作：用
mv -n source.txt dest.txt，目标存在直接跳过，不报错也不覆盖 - 留退路：用
mv -b source.txt dest.txt，覆盖前自动备份为dest.txt~（或按--suffix指定后缀） - 看过程：加
-v可确认实际发生了什么，比如mv -v *.conf /etc/conf.d/会逐行打印移动记录
注意：-i 和 -f 冲突时，后者生效；-n 优先级最高 —— 所以脚本里慎用 -f，它真会静默删数据。
跨文件系统移动大文件时，mv 其实是复制+删除
很多人以为 mv 总是“改 inode”，其实只在同一文件系统内才如此。一旦源和目标跨分区（比如从 /home 移到 /mnt/usb），mv 会退化为先 cp 再 rm，耗时长、占双份空间、中断即失败。
此时应主动判断：df . /mnt/usb 查看是否同设备；若不同，考虑用 rsync -a --remove-source-files 替代，它支持断点续传且更可控。
另外：mv 不保留扩展属性（如 SELinux context）、ACL 权限（除非用 -Z 或 --preserve=context），这点常被忽略。
