多线程重命名文件几乎无加速效果且易出错，因os.rename()是单点i/o操作，受文件系统目录锁限制，易触发winerror 183或fileexistserror；应采用单线程顺序执行预生成的路径映射表。
多线程对文件重命名几乎没加速效果，反而容易出错——因为 os.rename() 是系统调用，本质是单点 I/O 操作，CPU 并不瓶颈，而并发 rename 会触发文件系统锁、竞争条件或 FileExistsError / OSError: [WinError 183]。
为什么多线程 rename 大概率失败？
Windows 和多数 Linux 文件系统（如 ext4、NTFS）对同一目录下的 rename 操作加了目录项级互斥锁。多个线程同时调用 os.rename() 修改同一目录中的文件名，会争抢该锁，轻则阻塞，重则抛出 OSError: [WinError 183] 当文件已存在时，无法创建该文件（Windows）或 OSError: [Errno 17] File exists（Linux/macOS）。
- 即使目标文件名互不冲突，底层仍可能因目录 inode 更新顺序问题导致 race condition
-
threading.Thread启动开销 + GIL 在 I/O 场景下并无收益，纯属增加复杂度 - 错误日志里反复出现
[WinError 183]或FileExistsError就是典型信号
真正有效的替代方案：批量预生成 + 单线程顺序执行
把“重命名逻辑”和“执行动作”解耦：先扫描、校验、生成完整的新旧路径映射表，确保无重复目标名、路径合法、权限到位；再用单线程按序调用 os.rename()。这既安全又可控，且实际耗时接近理论最小值（I/O 串行不可并行化）。
- 用
pathlib.Path.glob()或os.walk()扫描，避免递归中修改目录结构引发FileNotFoundError - 所有新文件名必须通过
pathlib.Path.resolve()或os.path.abspath()校验是否落在目标目录内，防止路径遍历（如../evil.txt） - 提前检查目标路径是否存在：
if target.exists(): raise ValueError(f"Target {target} already exists") - 若需原子性保障（防中断后状态不一致），可先写一个临时 manifest JSON 记录映射关系，执行完再删
极少数可并行的场景：跨磁盘/跨文件系统重命名
只有当源文件和目标路径位于**不同挂载点**（例如源在 /mnt/disk1，目标在 /mnt/disk2）时，os.rename() 实际退化为 copy + unlink，此时 I/O 可并行。但必须显式判断：
import os
src_dev = os.stat("/mnt/disk1/a.txt").st_dev
dst_dev = os.stat("/mnt/disk2/b.txt").st_dev
if src_dev != dst_dev:
# 此时 rename 等价于 copy+delete，可考虑 concurrent.futures.ThreadPoolExecutor
# 但仍建议限制 max_workers ≤ 磁盘数 × 2，避免 I/O 饱和
- 用
shutil.move()替代os.rename()更稳妥，它自动检测跨设备并 fallback 到 copy - 即便如此，也别盲目开 100 个线程——实测 >8 个 worker 在 SATA 磁盘上反而降低吞吐
- SSD 上可稍放宽，但优先考虑
concurrent.futures.ProcessPoolExecutor配合shutil.copy2()+os.unlink()显式控制
真正卡住的是磁盘寻道和写入延迟，不是 Python 调度。想快，就换 NVMe、用 RAID0、关掉杀毒软件实时监控——而不是往 threading 里堆代码。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
