shutil.move比os.rename更适合批量移动文件，因其可跨文件系统自动降级处理（同设备用os.rename，跨设备用copy2+unlink），且保留元数据；但需手动创建目标父目录，且默认静默覆盖文件。
shutil.move 为什么比 os.rename 更适合批量移动文件
shutil.move 能跨文件系统移动，而 os.rename 在跨磁盘或挂载点时会直接报 OSError: [Errno 18] Invalid cross-device link。批量处理时你几乎无法提前判断所有文件是否在同一设备上，所以默认选 shutil.move 更稳妥。
它底层会自动降级：同设备走 os.rename（快），跨设备则先 shutil.copy2 再 os.unlink（稍慢但可靠）。
- 移动前不用手动检查源/目标是否在同一 mount point
- 保留原文件的修改时间、权限（
copy2行为保证） - 目标路径不存在时，
shutil.move不会自动创建父目录——这是最常踩的坑
目标目录不存在？必须先用 os.makedirs(..., exist_ok=True)
直接对不存在的目录调用 shutil.move("a.txt", "new_dir/b.txt") 会抛出 FileNotFoundError: [Errno 2] No such file or directory，错误信息里甚至不提是目标路径的问题。
正确做法是拆成两步：
立即学习“Python免费学习笔记（深入）”；
- 用
os.makedirs(os.path.dirname(dst), exist_ok=True)确保目标父目录存在 - 再调用
shutil.move(src, dst) - 注意：
exist_ok=True很关键，否则目标目录已存在时会报错
示例片段：
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
import os, shutil src = "data/file1.log" dst = "archive/2024/06/file1.log" os.makedirs(os.path.dirname(dst), exist_ok=True) shutil.move(src, dst)
批量移动时如何避免覆盖已有文件
shutil.move 默认会静默覆盖目标位置的同名文件，没有任何提示——这对大量文件来说风险极高。
安全做法是显式检查目标路径是否存在：
- 用
os.path.exists(dst)判断，存在则跳过、重命名或抛异常 - 如果要自动重命名（如加序号），建议用
pathlib.Path构造更清晰的逻辑，比如dst.with_name(f"{dst.stem}_{i}{dst.suffix}") - 不要依赖
shutil.move的返回值判断是否覆盖——它总是返回dst字符串，不反映实际行为
简单防覆盖示例：
if not os.path.exists(dst):
shutil.move(src, dst)
else:
print(f"Skip: {src} -> {dst} (target exists)")
移动大量小文件时性能卡在哪？别只怪 shutil.move
真正拖慢速度的往往不是 shutil.move 本身，而是频繁的系统调用和磁盘 I/O 调度。每移动一个文件都要触发一次 stat + rename 或 copy + unlink，10 万个文件就是 10 万次上下文切换。
- 用
glob.glob或pathlib.Path.rglob一次性获取全部路径，避免循环里反复os.listdir - 如果源目录结构需完整保留，考虑用
shutil.copytree+shutil.rmtree组合，有时反而更快（尤其 SSD 上） - Linux 下可尝试
subprocess.run(["mv", "-t", dst_dir, *files])批量调用系统mv，但丧失 Python 层错误控制和跨平台性
真正难处理的是“移动中出错怎么回滚”——shutil.move 没有原子性，中断后状态不可逆，得自己记日志或预生成操作清单。
