shutil.move()是python文件移动首选，但跨文件系统时退化为“复制+删除”导致变慢，且不自动覆盖同名文件；重命名场景下os.replace()更轻量原子。
shutil.move() 在 Python 3.11 中仍是文件移动与重命名的首选，但它的行为取决于源和目标是否在同一文件系统——跨磁盘移动会退化为“复制+删除”，且不自动处理目标已存在的情况。
shutil.move() 为什么有时慢得反常？
当 shutil.move() 检测到源路径和目标路径不在同一挂载点（例如从 /home 移动到 /mnt/usb），它会调用 shutil.copy2() 复制全部内容，再尝试删除原文件。这个过程既耗时又占磁盘空间，尤其对大文件或大量小文件。
- 用
os.stat(source).st_dev != os.stat(target_dir).st_dev可提前判断是否跨设备 - 若确认跨设备且需高效，改用
shutil.copy2()+os.unlink()并捕获异常，比默认move()更可控 - Python 3.11 没改变该逻辑，但
shutil.copy2()内部已优化了元数据复制路径，比旧版本略快
重命名失败：FileExistsError 怎么绕过？
shutil.move() 默认不覆盖目标文件，遇到同名文件直接抛 FileExistsError。这不是 bug，是设计使然——它只做“移动/重命名”，不做“替换”。
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 最简方案：移动前用
os.path.exists()检查目标，手动os.remove()或os.replace()（后者原子性更好） - 注意
os.replace()在 Windows 上可覆盖，在 Unix 上也原子，但仅适用于同文件系统；跨文件系统仍需先删后移 - 别依赖
shutil.move(src, dst, copy_function=shutil.copy2)的copy_function参数来绕过——它不控制覆盖逻辑，只影响复制方式
想原子重命名？优先用 os.replace() 而非 shutil.move()
如果只是同一目录下改名（如 log.txt → log.done），os.replace() 是更轻量、更可靠的选择：它在绝大多数 POSIX 系统和 Windows 上都保证原子性，且不触发复制逻辑。
-
os.replace("old.txt", "new.txt")成功即完成，失败即报错，无中间态 -
shutil.move()在同目录下底层也会调用os.replace()，但多了一层路径解析和权限检查，略重 - 唯一例外：目标路径含不存在的父目录时，
os.replace()直接报FileNotFoundError，而shutil.move()仍会失败——此时必须先os.makedirs(os.path.dirname(dst), exist_ok=True)
真正要注意的是：跨文件系统移动大文件时，别只盯着函数名，得看 st_dev 值；重命名场景下，os.replace() 往往比 shutil.move() 更直截了当。Python 3.11 没加新 API，但底层 C 实现的微优化让 copy2() 在某些 SSD 场景下延迟更低——不过这点提升远不如选对函数来得实在。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
