你是不是也遇到过这种场景某个文件夹里堆了一两万张照片、日志、导出报表文件名乱七八糟有的是IMG_20240101_001.jpg有的是最终版(1).docx还有的是微信图片_20240101123456.jpg。领导说“按日期排一下”财务说“把发票统一加个前缀”同事说“文件太多帮我按清单改名”。你选中第一个文件按下 F2输入新名字回车然后选中第二个F2输入回车……到第 500 个的时候眼睛花了手指开始机械地按键盘第 3000 个的时候你已经分不清是“命名”还是在“受刑”。文件重命名这件事看起来太小了小到很多人宁愿花三个小时手动处理也不愿意花三十分钟写一个脚本。但恰恰是这种“小到不起眼”的重复劳动最容易让人出错而且错了还不容易发现某个文件多打了一个空格某个序号跳过了 58某个扩展名被改成了.jpgjpg。等文件已经被上传、被同步、被其他人引用之后问题才暴露出来那时候再想找回原始文件名代价就高了。这篇文章要说的就是怎样用 Python 把“几万个文件批量重命名”这件事做得比手动 F2 更快、更稳、可回溯。批量重命名的难点从来不是“把名字改对”而是“有一套规则之后让规则一次跑完并且万一改错了还能知道刚才发生了什么”。如果你是 Python 新手这篇文章会从最基础的思路讲起代码可以直接复制运行如果你已经写过一些脚本后面关于防覆盖、试运行、备份清单和编码问题的工程建议也会帮你在生产环境里少踩几个坑。1. 为什么“几万个文件”不能靠手动重命名先看一组很直观的对比假设你有 5000 个文件需要重命名手动操作时每个文件大约需要 5 到 10 秒包括思考新名字、点中文件、按 F2、输入内容、回车。即使你手速飞快5000 个文件也要连续工作 7 到 14 个小时。更麻烦的是人在长时间重复操作中一定会疲劳而疲劳带来的错误不一定是“弹窗报错”而是“安静地改错”序列号跳了、字母大小写不统一、日期格式混用、不小心把两个文件重名导致系统自动加了(1)。等你回头检查时面对几千个文件你很难回忆起哪个环节出了问题而且这些错误往往要等文件被真正使用的时候才会被发现。使用脚本时情况完全不同。写脚本的第一版可能需要 15 到 30 分钟但脚本一旦跑通后续每次执行都只要几秒钟。更重要的是脚本是确定性的同一条规则作用于 5000 个文件要么全部按规则执行要么在某一个环节显式报错。你可以先在 5 个文件上试运行确认无误后再放到完整目录中执行还可以把“旧文件名、新文件名”的对应关系输出成清单。手动操作没有“试运行”概念你每一次按键都是正式执行。有人可能会说“Windows 下也可以全选文件然后按 F2系统会自动生成文件名 (1)、文件名 (2)这种带括号的序列。”这个功能确实支持简单加序号但它解决不了更常见的问题新增的前缀必须一样、不能基于 CSV 清单逐个映射、不能按文件的修改时间或拍摄日期自动排序、不能在旧文件名中只替换某一段字符串。一旦规则稍微复杂一点系统自带能力就不够用了。Python 的价值恰好在这里它不是帮你多按几次 F2而是把重命名这件事变成一段可编程、可复用、可审计的逻辑。需要特别说明的是批量重命名脚本并不一定要安装任何第三方库。Python 标准库中的os、pathlib、re、csv已经覆盖了绝大多数文件管理需求这也是我用它作为首选方案的原因跨平台、零依赖、在任何一台装有 Python 的电脑上都能直接运行。2. Python 批量重命名的基础原理无论你面对的是 5 个文件还是 5 万个文件批量重命名在脚本层面都可以拆成四个步骤确定目标目录、筛选需要操作的文件、计算新旧文件名的映射、执行真正的改名动作。理解这个流程比背诵某个 API 重要得多因为所有批量重命名脚本本质上都是这四个步骤的不同组合。第一步是“找到文件”。Python 里最传统的方式是os.listdir(directory)它会返回目录下所有文件和子目录的名称列表。如果你需要递归处理子目录可以使用os.walk(directory)它会生成一个三元组依次给出当前目录路径、子目录列表、文件列表。更现代的写法是用pathlib.Path(directory).iterdir()它会返回Path对象操作起来更直观。从 Python 3.4 开始pathlib 已经成为标准库的一部分实际项目中也越来越多人推荐使用它因为它把路径拼接、后缀提取、目录判断这些操作封装成了面向对象的方法。第二步是“筛选文件”。一万个文件通常不可能全都需要改名你需要根据后缀、文件名模式、修改时间、文件大小等条件过滤。最常见的过滤方式有几种用path.suffix判断扩展名用glob模块匹配模式比如*.jpg用re.search()做正则匹配。例如你只想处理.txt文件就可以写if path.suffix.lower() .txt如果你想处理名字里包含“合同”的文件就写if 合同 in path.stem。筛选逻辑越精确误操作风险越低。第三步是“构造新文件名”这是整个脚本的核心。新文件名通常由三部分构成主体、分隔符号和扩展名。你可以用日期、序号、业务编号、原文件中的某段字符串拼接出一个新主体再保持或修改原扩展名。这里最容易跳进来的坑是扩展名也是文件名的一部分如果不加处理替换逻辑可能会把report.docx改成report.docx_old或report_old.docx_old。因此规范的写法是先通过Path(path).stem取出不含后缀的文件主体通过Path(path).suffix取出扩展名最后在新名字里重新拼接而不是直接把整串旧文件名丢进字符串替换。第四步是“执行改名”。Python 中负责改名的是os.rename(src, dst)在 pathlib 中对应的方法是Path.rename(target)。rename 的本质是给文件系统发送一条“把路径 src 指向的 inode 移动到路径 dst”的操作它既可以改文件名也可以把文件移动到另一个目录。如果你只是改文件名请确保src和dst在同一个目录下如果跨目录要小心目标路径不存在、权限不足、磁盘分区不同等边界情况。另外rename 的覆盖行为需要单独处理Windows 上如果目标文件已存在rename 通常会直接报错类 Unix 系统上的行为则可能因为文件系统差异而不同。为了稳妥和安全实际脚本里应该在 rename 前先判断目标路径是否已存在。看一个最小的 Python 代码示例能立刻理解这一套流程。假设当前目录下有几个.txt文件你想给它们统一加一个前缀new_# 文件mini_rename.py from pathlib import Path folder Path(.) for path in folder.iterdir(): if path.is_file() and path.suffix.lower() .txt: new_name new_ path.name target folder / new_name if target.exists(): print(f跳过目标已存在{target}) continue path.rename(target) print(f{path.name} - {new_name})这段代码展示了完整的数据流遍历目录、判断文件类型、构建新名字、检查冲突、执行改名。很多初学者会把注意力放在rename本身但实际上前面的“筛选”和“新名字构造”才是决定成败的地方。规则设计得当rename 只是最后一步机械动作规则设计失误rename 会带着错误的名字一路执行到底。所以专业一点的脚本一定会加一个“试运行”模式先打印出旧名到新名的映射表等确认无误后才真正执行。3. 环境准备安装 Python 并搭一个安全目录如果你电脑上还没有 Python需要先装一个运行环境。Windows 用户可以去 Python 官网下载安装包安装过程中务必勾选“Add Python to PATH”选项否则后续在命令行执行python命令时系统可能提示找不到命令。macOS 和 Linux 用户一般自带 Python 3但版本可能比较旧而且系统对默认 Python 的管理比较严格不建议直接覆盖系统自带的 Python更稳妥的做法是单独安装一个较新的 Python 3 版本或者通过版本管理工具安装独立的运行环境。由于不同系统的安装路径差别很大这里不写死具体版本号安装时选择你操作系统对应的稳定版本即可。安装完成后打开命令行工具验证一下python --version如果命令正常输出类似Python 3.x.x的信息说明环境可用。如果提示python 不是内部或外部命令你需要检查安装时是否勾选了“Add to PATH”或者手动把 Python 的安装目录加入系统环境变量。在 Windows 上也可能遇到python命令无效但py命令有效的情况因为 Windows 的 Python 启动器会注册为py你可以在命令行先试一下py --version。如果你在同一个系统里装过多个 Python 版本建议在执行脚本前先确认当前命令行使用的是哪个 Python。命令where pythonWindows或which pythonmacOS/Linux可以看到实际路径。更保险的做法是进入项目目录后创建一个虚拟环境避免你的脚本影响到系统级 Python 环境python -m venv venvWindows 下激活虚拟环境的命令是venv\Scripts\activatemacOS / Linux 下是source venv/bin/activate激活后命令行提示符前面会出现(venv)的字样这说明后续的python命令都来自这个虚拟环境。对文件重命名这类脚本来说标准库就能完成任务所以实际上不装任何第三方库也可以运行。但虚拟环境仍然是个好习惯尤其是当你以后把脚本扩展为“读取 Excel 映射表”“批量移动文件到分类子目录”的时候第三方库不会污染全局环境也不会出现“这台机器能跑换台机器报缺包”的问题。真正容易被忽略的是“目录安全”。写文件重命名脚本时最好先在一个专门准备的测试目录中操作。你可以先创建一个空目录在里面放入几个测试文件比如test1.txt、test2.txt然后在脚本中把目录路径指向这个测试目录。第一次运行确认规则无误后再把路径改成真实目录。这个习惯花不了你两分钟却能把“误改几千个文件名”的风险提前拦截在第一轮。毕竟脚本不会像人一样在中途喊停它会安静地把规则执行完而“会安静地执行完”既是脚本的优点也是危险所在。4. 设计重命名规则先想清楚改什么再写代码很多人动手写重命名脚本时第一反应是打开编辑器写os.rename写完才发现自己根本不知道目标文件名应该长什么样。这其实是把顺序搞反了。批量重命名第一步不是写代码而是把规则描述清楚。你可以试着用一句普通中文描述你的需求“把所有 jpg 图片按照拍摄时间排序然后改成20240101_001.jpg这种格式”“把所有日志文件里的空格替换成下划线”“根据 Excel 里的旧名和新名对照表逐个改名”。这句话越清晰后续写代码就越快。实际工作中重命名规则通常可以归纳为几类模式。第一类是“加前缀或后缀”例如给所有发票文件加2024_前缀或给所有简历加应聘_后缀。这种规则最简单只用字符串拼接即可。第二类是“排序后加序号”常用于照片、扫描件和导出文件。你需要先确定排序字段按文件名排、按修改时间排、按创建时间排还是按拍摄时间排如果只是给文件加上两位或三位数的序号可以使用 Python 的sorted()函数配合适当的 key 参数再结合zfill()方法补零让序号保持固定宽度这样文件管理器排序时不会出现10排在2前面的问题。第三类是“替换或清理非法字符”适用于从网页、微信、旧系统导出的文件名。Windows 文件系统不允许文件名包含\ / : * ? |当文件从别的平台下载到本地时这些字符必须被替换。你还需要考虑去掉首尾空格、连续空格转下划线、中文全角字符转半角字符等细节。第四类是“基于外部清单映射改名”也就是“根据 Excel 或 CSV 中的新旧名字对照表来重命名”。这类需求在企业场景里特别常见业务系统导出一个文件清单用户整理好新名称后由脚本统一执行。这种方案的优点是非常灵活因为映射关系完全由人工决定脚本只负责忠实地执行。第五类是“重命名时移动文件到分类目录”例如把 jpg 图片按年份移动到2023、2024文件夹把 PDF 按项目编号移动到对应项目目录。这类操作的本质仍然是生成“源路径到目标路径”的映射只是目标路径包含子目录在执行前需要先创建父目录。不管哪种规则我建议你在动手前先明确回答四个问题。问题一本次操作是否包含子目录如果包含是用os.walk递归遍历所有子目录还是只处理当前目录一层问题二目标文件如何筛选扩展名是否统一会不会把已经符合命名规范的文件又改了一遍问题三新文件名是否可能冲突比如两个不同的旧文件生成了同一个新文件名这种情况必须提前拦截否则会静默覆盖或报错。问题四如果执行中断或改错了有没有办法恢复这就是后面要讲的“先试运行、输出日志、保留映射清单”的原因。回答完这四个问题你其实已经把 80% 的脚本写完了。剩下的只是在代码里把这些决策表达出来。5. 完整示例三个可直接运行的 Python 重命名脚本考虑到不同读者需求差异很大我准备了三个脚本分别对应最常见的三种场景。场景一是“排序后加序号前缀并规范扩展名”场景二是“按 CSV 对照表逐个映射改名”场景三是“用正则表达式批量修改文件名片段”。三个脚本都只依赖 Python 标准库可以直接复制运行。5.1 场景一给照片 / 文件按时间排序后添加序号前缀假设你的文件夹里有很多照片它们现在的文件名是随机字符但文件的修改时间能反映拍摄顺序。你想把它们改成photo_0001.jpg、photo_0002.jpg这种格式。这里要注意先把文件列表按修改时间排序再生成连续序号避免直接遍历目录时系统返回顺序不稳定。# 文件add_sequence_prefix.py import os from pathlib import Path def batch_add_sequence(folder: str, prefix: str photo, digits: int 4): base_dir Path(folder) if not base_dir.is_dir(): print(f目录不存在{base_dir}) return # 第 1 步筛选出需要处理的文件并按照修改时间排序 files [ path for path in base_dir.iterdir() if path.is_file() and path.suffix.lower() in {.jpg, .jpeg, .png, .mov, .mp4} ] files.sort(keylambda p: p.stat().st_mtime) total len(files) for index, path in enumerate(files, start1): seq str(index).zfill(digits) new_name f{prefix}_{seq}{path.suffix.lower()} target base_dir / new_name if target.exists(): print(f跳过目标文件已存在{target.name}) continue path.rename(target) print(f{path.name} - {new_name}) print(f处理完成共处理 {total} 个文件) if __name__ __main__: # 改成你实际的目录路径 batch_add_sequence(rD:\photos, prefixphoto, digits4)这段代码有几个关键点值得说明。一是目录路径使用Path对象而不是字符串拼接这样在 Windows 和 macOS 上都不会出现反斜杠或正斜杠的兼容问题。二是用path.suffix.lower()统一转小写避免出现同一个文件被改成.JPG而其他是.jpg的不一致情况。三是用path.stat().st_mtime取文件的最后修改时间作为排序依据。在很多场景下导出文件的“修改时间”并不等于“业务时间”如果你想按文件名中的日期排序可以换个 key 函数比如从文件名里提取日期字段。四是在执行rename之前先判断target.exists()这样即使脚本中途出现命名规则漏洞也不会直接覆盖已有文件。5.2 场景二根据 CSV / Excel 导出的对照表批量改名这是“如何根据 Excel 表格批量重命名对应的文件”这种需求的标准解法。Excel 本身不擅长批量执行文件系统操作但它非常方便人工编辑“旧文件名—新文件名”的对应关系。你可以先在 Excel 里整理好两列第一列是当前文件名第二列是希望改成的新文件名然后另存为 CSV 文件。Python 脚本读取 CSV逐行执行改名。# 文件rename_from_csv.py import csv from pathlib import Path def rename_from_csv(folder: str, csv_path: str): base_dir Path(folder) if not base_dir.is_dir(): print(f目录不存在{base_dir}) return with open(csv_path, r, encodingutf-8-sig, newline) as f: reader csv.reader(f) header next(reader, None) if header: print(f表头{header}) success_count 0 skip_count 0 error_count 0 for row in reader: if len(row) 2: continue old_name row[0].strip() new_name row[1].strip() if not old_name or not new_name: continue src base_dir / old_name dst base_dir / new_name if not src.exists(): print(f错误源文件不存在{old_name}) error_count 1 continue if dst.exists(): print(f跳过目标文件已存在{new_name}) skip_count 1 continue src.rename(dst) print(f{old_name} - {new_name}) success_count 1 print(f处理完成成功 {success_count}跳过 {skip_count}失败 {error_count}) if __name__ __main__: rename_from_csv(rD:\files, rD:\rename_map.csv)CSV 文件示例rename_map.csv内容如下旧文件名,新文件名 report_old.docx,report_2024.docx IMG_1234.jpg,photo_001.jpg 图片(1).png,扫描件_01.png这里用utf-8-sig编码读取 CSV是为了兼容 Windows 下 Excel 导出 CSV 时常见的 BOM 头。如果你用普通utf-8读取第一列第一行可能多出一个不可见字符\ufeff导致源文件名查找失败。中文文件名在 Windows 下很容易遇到这种编码问题这是一个很实际的坑。从这个脚本的实现也能看到按照 CSV 映射来重命名的好处是人工对规则的掌控度最高。Excel 里可以筛选、排序、批量填充改完之后脚本只做“翻译”不产生任何额外判断。它唯一需要保证的是CSV 里的旧文件名必须和文件系统中的实际文件名完全一致包括空格、括号、扩展名的大小写。5.3 场景三用正则表达式批量替换文件名片段如果你不想逐个列举新名字而是希望“把文件名里的空格替换为下划线”“把文件名中的日期从 2024-01-01 改成 20240101”“把文件名开头的序号规范化”那就可以用正则表达式来定义替换规则。正则的好处是强大风险是容易出现“误伤”所以运行前务必先打印预览结果。# 文件regex_batch_rename.py import re from pathlib import Path def regex_batch_rename(folder: str, pattern: str, repl: str, dry_run: bool True): base_dir Path(folder) if not base_dir.is_dir(): print(f目录不存在{base_dir}) return for path in base_dir.iterdir(): if not path.is_file(): continue new_name re.sub(pattern, repl, path.name) if new_name path.name: continue target base_dir / new_name if target.exists(): print(f跳过目标文件已存在{target.name}) continue print(f{path.name} - {new_name}) if not dry_run: path.rename(target) if dry_run: print(试运行模式以上只是预览未真正改名。确认无误后设置 dry_runFalse) if __name__ __main__: # 把文件名中的空格替换为下划线 regex_batch_rename(rD:\downloads, r\s, _, dry_runTrue)这段代码有一个非常重要的设计dry_run参数。当dry_runTrue时脚本只计算新名字并打印预览不执行真正的rename操作。很多生产环境事故都发生在“规则没看清就直接执行”的时候而 dry_run 模式让脚本先在文件系统上“模拟跑一遍”帮助你在真正影响文件之前发现规则问题。类似的设计在数据库迁移、CI/CD 发布等场景中也是标配先看看将要发生什么确认无误后才正式操作。正则替换需要格外小心元字符。比如你只想替换点号.但在正则表达式里点号能匹配任意字符所以你必须写成\.只想匹配行首可以用^。如果你没有足够的正则需要建议先用普通字符串替换str.replace()它不需要转义语义也更直观。正则是一个强大的工具但它不应该成为默认选项只有规则确实复杂到需要分组、匹配多个格式时才值得引入。6. 运行效果与验证流程把脚本保存到本地后建议按下面的顺序执行。第一步找一个测试目录在里面放三五个测试文件跑一遍脚本。观察输出的“旧文件名 - 新文件名”日志是否符合预期。如果你使用了dry_runTrue的模式这一步不会真实改名输出就是你要审查的预览结果。以 5.1 的脚本为例假设目录里有四个文件运行后预期输出大致如下IMG_20231201_001.jpg - photo_0001.jpg IMG_20240115_002.jpg - photo_0002.jpg DSC_0001.JPG - photo_0003.jpg 微信图片_20240101123456.jpg - photo_0004.jpg 处理完成共处理 4 个文件看到这样的输出不要急着觉得“完事大吉”而是应该检查以下几点。检查点一序号补位是否正确1是否补成了0001还是直接变成了1检查点二扩展名大小写是否统一原文件是.JPG新文件名是否变成了.jpg检查点三是否存在目标文件已存在被跳过的情况如果很多文件都跳过了很可能你的规则让多个旧文件映射到了同一个新名字。检查点四日志中是否出现“源文件不存在”或“目标文件已存在”等错误信息出现后不要忽略先搞清楚原因。如果预览没有问题再切换到真实目录执行。执行之前强烈建议你先把当前目录下的文件清单保存一份备份记录。不一定非要复制一份文件因为几万个文件占用空间很大但至少把“旧文件名清单”导出来方便日后追溯。一个简单可靠的方式是执行下面的命令生成一份当前文件名快照python -c from pathlib import Path; p Path(r你的目录); print(\n.join(x.name for x in p.iterdir() if x.is_file())) before_rename.txt如果你希望更结构化的记录可以在脚本里加入写日志的逻辑把每一条改名操作都写入rename_log.csv包含旧名、新名、操作时间。后面如果发现某个文件改名错误就能根据这份日志反向恢复。执行完毕后再查看一遍目录内容用一个简单的方式验证数一下文件数量是否和操作前一致。Windows 资源管理器底层和脚本读到的文件系统视图是一致的所以通常不会无故丢失文件。真正需要警惕的是“覆盖”导致的文件数量不变、但内容被替换。因此所有脚本里都要有“目标已存在则跳过”的逻辑这比任何事后检查都更可靠。最后打开几个有代表性的文件确认内容没有损坏。改名只修改文件系统里的目录项不碰文件内容正常情况下内容不会变化但如果你操作的是被其他程序占用的文件可能会遇到权限错误这一点如果出现重启对应程序后重试即可。如果执行过程中出现了报错第一步不要惊慌先翻看脚本输出的第一条错误信息。绝大多数问题不外乎几类路径写错、权限不足、文件被占用、文件名编码异常、目标已存在。这些在前面示例代码中大部分都做了显式处理你只要根据报错提示对照检查即可。7. 常见问题与排查方法实际运行中你大概率会遇到下面这些情况。我整理成了表格方便你在出错时快速定位。问题现象可能原因排查方式解决方案提示“目录不存在”路径写错或字符串里的反斜杠转义错误打印实际传入路径确认目录是否存在推荐用Path(rD:\folder)原始字符串或直接使用正斜杠Path(D:/folder)弹出PermissionError文件被其他程序占用或者没有写入权限查看报错文件名确认是否打开了对应文件关闭占用程序以管理员身份运行命令行先处理可以访问的文件弹出FileExistsError目标文件已经存在检查脚本中的target.exists()判断是否生效增加“目标存在则跳过或加后缀”的策略不要直接覆盖部分文件没有被改名筛选条件太严格或文件后缀与预期不一致打印参与处理的文件列表调整suffix条件统一大小写后再判断CSV 映射改名时提示“源文件不存在”CSV 中的文件名包含不可见字符或 Excel 自动加了 BOM打印repr(old_name)查看是否有\ufeff用utf-8-sig读取 CSV清理列首尾空格中文文件名变成乱码命令行编码或系统区域设置导致检查终端输出确认操作系统语言和代码页在 Python 文件头部不加特殊声明直接使用字符串必要时指定encodingutf-8读写文件递归子目录时找不到完整路径直接用了文件名而不是绝对路径检查os.walk返回的 root 是否拼接完整使用Path(root) / filename构造完整路径文件被改名后顺序乱出现10排在2前面序号没有补零查看生成的新文件名使用str(index).zfill(位数)或格式化f{index:04d}脚本执行到一半中断中途遇到某个文件冲突异常没有捕获查看中断时的日志确认最后一个成功改名的文件在 rename 外层加try/except单个文件失败时记录日志但不中断整体流程我再展开说几个容易忽略但实际工作中发生频率极高的问题。第一路径拼接的坑。新手写os.rename(old_path, new_path)时经常忘记把目录前缀拼回去。比如for filename in os.listdir(D:/photos)得到的filename只有纯文件名你需要用os.path.join(D:/photos, filename)才能变成完整路径。如果直接拿一个不带目录的文件名去调用 renamePython 会默认操作“当前工作目录”下的文件而当前工作目录可能和你脚本所在的目录完全不同。使用 pathlib 能在一定程度上避免这个问题因为Path对象做除法运算时不会忘记父路径。第二Windows 平台大小写不敏感的坑。Windows 文件系统默认不区分文件名大小写所以report.docx和Report.DOCX会被视为同一个文件。如果你在脚本里想把文件统一改成大写扩展名需要注意old_name new_name这种字符串比较在 Windows 上可能因为大小写不同而判断为“不同”但文件系统却认为它们是同一个文件。稳妥的做法是构造新名字后同时判断字符串是否真的变化了以及目标路径是否真的指向不同的 inode。如果你不确定最安全的策略是只做小写替换或先记录日志再执行避免系统把覆盖操作解释成空操作。第三正则表达式的误匹配。举例来说很多初学者想“把文件名中的空格替换成下划线”于是写re.sub( , _, filename)这没问题。但如果你想“把多个连续空格替换成一个下划线”并写成了re.sub(\\s, _, filename)要注意\s不仅匹配空格还匹配制表符和换行符。文件名里一般不会有换行但可能有意想不到的 Unicode 空白字符例如全角空格和不断行空格普通\s不一定能覆盖。这个时候先用repr()查看文件名里的真实字符往往比反复调整正则更快。第四文件名里包含特殊字符导致日志输出乱码或者写入 CSV 失败。处理这类情况的关键原则是尽量不要人为干预编码让 Python 在读写文件时统一使用 UTF-8如果 CSV 需要被 Excel 用 Windows 打开写入时可以考虑utf-8-sig编码因为 Excel 对带 BOM 的 UTF-8 识别更好。如果脚本只是打印到控制台Windows 默认代码页如果设置不当中文可能出现乱码这通常不会影响实际改名只是显示问题真想解决可以在命令行执行chcp 65001切换到 UTF-8 代码页再看输出。8. 工程化建议把一次性脚本变成可靠工具如果你只是临时处理一次文件上面的脚本已经够了。但如果你是开发、运维、测试或者经常帮同事处理文件整理需求我建议你再往前走一步把脚本写得具备“工具”属性。工具和一次性脚本的区别不在于功能多炫而在于“安全边界是否清晰”“日志是否完整”“是否容易复用”。第一个建议把 dry_run 做成默认开关。也就是说不管脚本功能多简单总要提供一个参数让操作者可以“先预览不执行”。很多 CLI 工具比如 Kubernetes 的kubectl --dry-run、数据库迁移工具的草稿模式都有类似设计批量文件操作同样值得借鉴。dry_run 开关的成本极低不过是用一个布尔变量控制最终是否执行rename但它能避免大量误操作。第二个建议把所有执行记录写入日志文件。日志字段至少包括操作时间、源文件完整路径、目标文件完整路径、是否成功、失败原因。日志的价值在事后不是事前。如果三天后有人跑来问“上周你帮我改名的时候那个数据汇总(1).xlsx是从哪个文件改来的”你能直接查日志回答而不是重新翻找文件。实际做法是在脚本开头打开一个rename_log.csv在每次 rename 前后写入一行记录。如果操作中断日志还能告诉你断点在哪里。第三个建议对异常做单文件隔离。默认逻辑应该是“单文件失败不影响整体流程但必须记录失败原因”。不要因为某一个文件被占用就让后面 9999 个文件全部停在原地也不要用一个裸try/except吞掉所有异常导致最后只看到“处理完成”却不知道哪些文件实际没改。推荐下面的写法import traceback failures [] for path in files: try: new_path ... path.rename(new_path) except Exception as e: failures.append((path.name, str(e))) traceback.print_exc() print(f成功 {len(files) - len(failures)} 个失败 {len(failures)} 个) for name, error in failures: print(f失败{name}原因{error})第四个建议脚本执行前先做一次“目标目录状态快照”。这不是必须的但如果文件数量很大、价值很高、命名规则复杂花几秒钟导出当前文件名清单是非常值的保险动作。有了清单即使最坏情况发生你也能知道改名前有哪些文件配合日志里的新旧对照能反向恢复。如果文件原本在回收站不可恢复旧名清单就是唯一的恢复线索。第五个建议规则尽量使用映射表而不是写死在代码里。对于团队协作或者重复使用的场景建议把命名规则以 CSV、JSON 或 Excel 的形式放在脚本外面让非技术人员也能维护。比如运营同事整理好了新旧文件名对照表开发同事只需要维护一个通用的读 CSV 改名脚本双方不互相等待也不容易改乱代码。数据驱动的方式比硬编码更灵活也更好测试。第六个建议涉及生产环境或重要数据时先在克隆目录上做演练。不要觉得“这些文件我可以随便造”很多情况下“随便”会造成不可逆损失。把一小批真实文件复制到一个测试子目录执行完整脚本比对结果再切到真实目录时你心里会踏实很多。很多生产环境事故不是规则写错而是执行者没有给自己留验证空间。9. 总结批量重命名的核心方法论与后续学习方向回到开头那个问题几万个文件怎么快速重命名答案不是“更快的 F2”而是“把重命名变成一次可审计、可回滚、可复用的代码执行”。你需要掌握的内容其实只有几块用 pathlib 或 os 遍历目录用文件属性或正则筛选目标用字符串格式化或 CSV 映射构造新名字最后用 rename 执行并且在整个过程中用 dry_run、日志、冲突检测、异常隔离来保护自己。这个方法论不只适用于文件重命名它几乎是所有“批量操作”类脚本的共同骨架无论批量修改数据库记录、批量调用接口、批量上传对象存储核心都是“先筛选、再生产目标、再执行、再记录”。如果你是个 Python 新手这篇文章里的代码不可能一次记住但你可以先保存起来遇到实际需求时照着改。真正重要的不是背下 API而是建立一种感觉重复劳动出现时先停一下想清楚这件事是否适合写成脚本。只要操作是“批量”“规则明确”“需要重复执行”三者之一就值得花时间写脚本。下一步深入学习时我建议按这个顺序展开。先熟练使用pathlib因为它在路径操作上比os.path更符合现代 Python 的写法代码可读性也更高。接着学习re模块的常用语法正则不一定要精通但能读懂和写出常见的替换模式足够覆盖大部分文件名清洗场景。然后可以了解concurrent.futures的多线程知识虽然重命名通常是磁盘 IO 操作瓶颈往往不在 CPU但在网络磁盘或对象存储场景下多线程能显著提升速度而且 Python 的多线程写法并不复杂。想做得更完整的话可以学习click或typer这类命令行库把脚本封装成带--dry-run、--log-file参数的正式 CLI 工具让同事不需要阅读代码就能安全使用。最终我想提醒你的是永远不要在第一次运行时就处理全部文件。先操作两个文件然后操作二十个文件确认无误后再放行到全部文件。几万个文件看起来多但对脚本来说一个文件和一万个文件的逻辑一模一样。做错一万个文件的代价远大于多看两分钟预览日志前者消耗的心力和数据恢复成本足够再写十个脚本了。