一直觉得文件操作是Python里最“拧巴”的一块。你说它简单吧日常写脚本天天在用open()一开一关就完事你说它难吧等你在Windows上调通一个路径问题、在Linux上处理完一个编码坑、在生产环境排查完一个文件句柄泄漏之后才明白这里面到处是细节。尤其是从零基础往进阶走文件操作往往是最先让新手碰壁的地方——因为它不像是列表字典那种纯内存结构文字明明写进去了文件里却没有读文件明明看着好好的换一台机器就抛UnicodeDecodeError路径拼接按字符串拼一不小心就把整个目录结构拼没了。这篇文章不搞那种“从入门到放弃”的祖传清单。我从实际开发的角度把文件操作的底层逻辑、常用API、常见隐患和进阶玩法拆开揉碎。不管你是刚学Python的小白还是已经写了几年脚本想回头补补基本功的人应该都能在这里找到点没被注意到的细节。我会穿插一些真实场景下的代码和踩坑记录让你直接拿来用、照着写就行。1. 文件操作的整体设计与思路拆解1.1 为什么文件操作是程序员的基本功文件是程序和数据交换的主要媒介。你程序跑出来一堆结果要落到磁盘上这是普通文件配置项要持久化这是配置文件日志要追加记录这是日志文件数据库本质上也是一套精心设计的文件系统。所以文件操作不是Python特有的需求而是几乎所有语言都绕不开的基础能力。Python在这块的优势在于——标准库提供了从底层open()到高层pathlib的完整体系而且跨平台的兼容性做得相对到位。从零基础到进阶的路线其实就对应着三个阶段。第一阶段是“能读写”——会用open()打开文件会读出来、写进去知道with做自动关闭。第二阶段是“懂取舍”——知道什么时候用文本模式、什么时候用二进制模式知道newline参数在Windows上的意义知道编码不一致怎么处理知道大文件不能一次性read()出来。第三阶段是“玩得转”——能用pathlib优雅地处理路径会用os.walk遍历目录树做批处理能自己写一个健壮的文件处理脚本而不至于崩溃到一半。大多数人在第二个阶段就劝退了因为编码和路径这两个东西实在是太烦。但我可以负责任地告诉你这些坑其实都是有规律可循的摸清了之后反而会觉得文件操作在Python里是被设计得相当贴心的。1.2 从内存到磁盘文件读写的本质过程我刚开始学的时候有个很大的困惑为什么写入文件之后数据不是立刻出现在文件里偶尔程序意外崩溃文件里的内容还是旧的这个问题直接关系到你对文件操作的理解深度。实际上f.write()做的事情是把数据写入到“缓冲区”buffer里缓冲区是内存中的一块区域而不是直接落到磁盘。系统为了提高性能会攒一批数据再一次性写盘。这就是为什么你写完不f.close()或flush()数据可能会丢。close()本身会自动调用flush()把缓冲区里残留的数据都刷到磁盘上并关闭文件描述符。类比一下就好理解了。缓冲区就像快递驿站你把包裹数据交给驿站驿站不会每收一件就立刻跑一趟物流而是攒到一车再发。flush()就是催驿站马上发车close()则是发完车之后把这个站点关门歇业。这个底层机制衍生出了很多实践准则大文件要分块写别一次性写入超大内容写完重要数据要手动flush()如果程序马上要处理这个文件不要指望close()之前的隐式刷新时机多个进程同时写同一个文件时要考虑用with加锁来避免写入交错。1.3 选对抽象层级三种文件处理方式的选择Python给文件操作提供了三套工具对应不同的使用层次。第一层是内建函数open()直接返回文件对象适合大多数普通场景比如读写文本、读写字节、追加日志等。第二层是io模块提供更底层的流接口以及StringIO、BytesIO这种内存中的“伪文件”——可以把字符串或字节当作文件来处理这在逻辑抽离时特别有用比如你想让一个函数既能处理真实文件路径又能处理内存中的文本内容。第三层是os和pathlib模块负责路径管理、目录遍历、文件状态查询、删除/重命名/移动等“文件系统操作”而不是内容读写本身。我见过不少人把这三层的职责混着用比如用os.system(mv ...)移动文件或者用open()的方式去判断文件是否存在。实际正确的做法是路径和元数据操作用pathlib或os内容读写的核心永远用open()及其各种模式。各司其职之后代码可读性和健壮性都会上一个台阶。2. 核心细节解析open()函数和各种模式背后的门道2.1 open()的完整参数签名和模式选择open()的完整签名在Python 3里是这样的open(file, moder, buffering-1, encodingNone, errorsNone, newlineNone, closefdTrue, openerNone)平时90%的情况你只需要用前三个参数但后面这些参数每一个都有明确的用途。这里重点说mode。mode是一个字符串由几个字符组合而成。基础字符有三个r表示读w表示写且会清空原文件a表示追加写入位置在文件末尾还有一个特殊的x表示排他创建如果文件已存在直接报错这个在防止覆盖时特别好用。然后可以叠加表示读写都允许b表示二进制模式t表示文本模式默认。组合模式的一些细节容易踩坑r可读也可写但不会清空文件。写入从文件头开始覆盖对应字节数其余内容保留。这通常是坑最少的更新模式。w可读也可写但一打开就把文件清空了。如果你不小心拿w打开了本来要保留的文件哭都来不及。a可读也可写写入总是在末尾不受当前读写位置影响。x模式只能配合w其实是本身就代表写不能x或xb等随意组合虽然xb是可以的。我强烈建议新手养成一个习惯每次open()之前先在脑子里过一遍——我打开这个文件是为了读还是写要不要保留原有内容允不允许并发写想清楚了再选mode能避免大部分误覆盖事故。2.2 文本模式和二进制模式别混着用文本模式t和二进制模式b的区别不只是能不能读写中文字符的问题而是数据的基本单位不同。在文本模式下你读写的是字符串Python会自动处理换行符和编码转换。在二进制模式下你读写的是bytes对象不做任何转换。这个设计带来了两个常见错误第一个错误是把二进制文件用文本模式打开。比如图片、压缩包、Excel旧格式.xls如果你用open(..., r)去读会得到一串乱码——严格来说可能会在遇到非法UTF-8字节时直接报UnicodeDecodeError也可能返回包含乱码的文本总之数据被搞坏了。正确的做法是用rb模式读取。第二个错误是把文本文件用二进制模式打开然后写入。如果你从网络上抓取HTML用wb按字节写入这是合理的但如果你从open(r)读出来的是str却用wb去写就会抛TypeError因为字节流和字符流不能混写。一个实用的判断标准这个文件的“语义”是给人读的文本代码、JSON、日志、配置还是给程序读的字节流图片、音视频、序列化对象、压缩包前者用t模式后者用b模式。两边都有换行和编码的问题只是表现形式不同。2.3 with语句和上下文管理器为什么不能只靠close()初学者最常见的写法是这样f open(data.txt, r) data f.read() f.close()看起来没什么问题但隐患在于如果在f.read()和f.close()之间抛了异常f.close()就永远不会执行文件句柄就一直开着。在Windows上被打开的文件很可能被其他程序锁定无法删除或重命名在Linux上句柄数量是有限的通常是几百到几千长时间不关闭会导致“Too many open files”错误。更优雅的方案是with语句with open(data.txt, r) as f: data f.read()with会在代码块结束时自动调用f.close()即使内部抛异常也会走清理逻辑。这是因为文件对象实现了上下文管理协议即__enter__和__exit__。你可以把with看作“自动收尾的保险”。对于需要同时操作多个文件的场景推荐把多个with写在一行with open(a.txt, r) as src, open(b.txt, w) as dst: dst.write(src.read())这样两个文件都会在退出时自动关闭逻辑上也更紧凑。如果你习惯旧式的try/finallywith的本质其实就是一个帮你封装好的try/finally。2.4 编码问题UnicodeDecodeError的完整解法编码是中文环境下文件操作绕不开的话题。默认情况下Python 3 在文本模式下使用系统的默认编码在Windows上通常是GBK在Linux/macOS上通常是UTF-8。这意味着同一个代码在Windows读写UTF-8文本的方式跟在Linux上是不同的这在跨平台运行时非常容易出问题。最朴素的解法就是写文件时明确指定encodingutf-8读文件时也明确指定encodingutf-8。把所有你控制范围内生成的文件统一用UTF-8能免掉90%的编码烦恼。但还有10%的烦恼来自那些你不知道编码的旧文件。比如Windows下用记事本另存的txt可能是ANSI本地代码页、UTF-8带BOM、UTF-16等。当UnicodeDecodeError出现时可以尝试以下策略with open(path, r, encodingutf-8, errorsreplace) as f: content f.read()errorsreplace让无法解码的字节替换成替代字符通常是这样程序不会崩但你可能要容忍少量乱码。如果不想丢内容也可以依次尝试几种候选编码比如utf-8、gbk、latin-1用哪个能完整解码就采用哪个。关于BOM字节序标记有一个值得注意的坑。用utf-8-sig编码写入文件时会自动加BOM头读取时用utf-8-sig则可以自动剥掉BOM。如果你用普通utf-8去读带BOM的文件第一行开头会多出一个看不见的字符\ufeff轻微影响字符串比较和JSON解析。所以如果你不确认文件来源读文件时用utf-8-sig反而是个稳妥的选择。3. 实操过程从零到进阶的完整文件操作示范3.1 基础读写一行行读、一行行写、追加内容先来一套最常用的文本处理流程。# 逐行读取并打印行号适合处理大日志文件 with open(system.log, r, encodingutf-8) as f: for idx, line in enumerate(f, 1): print(f第{idx}行{line.strip()}) # 过滤并写出到新文件 with open(system.log, r, encodingutf-8) as src, \ open(filtered.log, w, encodingutf-8) as dst: for line in src: if ERROR in line: dst.write(line)这里有个性能细节for line in f是迭代文件对象的行迭代器内部会用缓冲区读一大块数据再按行切分所以既省内存不会一次性把整个文件读进内存又高效。相比之下f.readlines()会把所有行读成一个列表文件很大时可能把内存占满新手要注意区分。追加内容的场景也很常见with open(log.txt, a, encodingutf-8) as f: f.write(新的日志记录\n)追加模式的好处是保留原有内容只从文件末尾开始写。适合日志采集、累计统计等需求。3.2 路径处理从字符串拼接升级到pathlib很多初学者习惯用字符串拼接来做路径path /home/user/data/ filename这在Linux/macOS上还能跑但换到Windows就翻车了——因为你可能得用反斜杠\。而且如果目录字符串末尾忘记加分隔符拼出来的路径就会缺一段。Python 3.4之后官方推荐用pathlib用Path对象来表示路径直接用/运算符拼接跨平台无压力from pathlib import Path base Path(/home/user/data) config base / config.json print(config.read_text(encodingutf-8))Path对象有很多好用的方法exists()判断是否存在、is_file()判断是否为文件、is_dir()判断是否为目录、mkdir(parentsTrue, exist_okTrue)递归创建目录、rename()重命名、unlink()删除文件、glob()模式匹配文件列表。我实际用下来Path.glob简直是批量处理的利器。比如找出某个目录下所有.py文件for py_file in Path(src).rglob(*.py): print(py_file)rglob会递归遍历所有子目录省去了手写os.walk的麻烦。如果只需要顶层一层用glob即可。有一件事要提醒Path对象可以直接传给open()但如果你想拿到真正的字符串路径用str(path)或者path.as_posix()转一下。在部分老库或者subprocess调用场景里可能需要字符串形式的路径。3.3 目录遍历与批处理用os.walk做深度扫描pathlib提供了优雅的接口但说到目录树的灵活遍历os.walk依然是标准方案。它返回三部分当前目录路径、子目录列表、文件列表。经典用法是统计目录大小import os total_size 0 for root, dirs, files in os.walk(/path/to/folder): for name in files: filepath os.path.join(root, name) total_size os.path.getsize(filepath) print(f总大小{total_size / 1024:.2f} KB)如果你在遍历时需要跳过某些目录比如node_modules、.git可以直接修改dirs列表的内容把想跳过的目录名移除掉。比如for root, dirs, files in os.walk(.): dirs[:] [d for d in dirs if d not in {.git, __pycache__, node_modules}] for name in files: # 处理文件 pass这是os.walk的一个隐藏特性在遍历过程中就地修改dirs会影响后续遍历的目录范围。比跑到一半再continue要干净得多。3.4 大文件的高效处理分块读取不能偷懒处理超大文件比如几个GB的日志、下载到一半的备份文件最忌讳的就是content f.read() # 一次性读入内存GG正确做法是分块读取控制每次读入的字节数with open(bigfile.bin, rb) as f: while True: chunk f.read(1024 * 1024) # 每次1MB if not chunk: break process(chunk) # 处理这块数据对文本文件也可以借助for line in f按行迭代。如果行本身特别长比如JSON每行几个MB则需要配合readline()或者自定义分隔符。我的经验是能用迭代器解决就绝不用一次性读取不得已要读取时设定明确的缓存上限比如1MB、4MB并根据内存余量做调整。有时候文件不大但数量巨大比如几万个小文件那瓶颈就在磁盘IO和每个文件的open/close开销上。这时可以考虑用concurrent.futures做并发读取但要注意文件句柄数量的上限。3.5 临时文件与内存文件两个高级便利工具进阶阶段有两个工具能帮你写得更顺手。第一个是tempfile模块的高层接口TemporaryFile。它会为你创建一个临时文件默认在系统临时目录下并以wb模式打开。最关键的是它在close()后自动删除不需要你手动清理。特别适合中间结果、缓存、单元测试时生成临时数据import tempfile with tempfile.TemporaryFile(modewt, encodingutf-8) as tmp: tmp.write(临时数据) tmp.seek(0) data tmp.read()第二个是io.StringIO。它把字符串伪装成文件对象可以像操作文件一样对它读写适合函数抽象即让函数既能处理文件路径也能处理内存字符串from io import StringIO sbuf StringIO() sbuf.write(第一行\n) sbuf.write(第二行\n) content sbuf.getvalue() # 第一行\n第二行\n同类还有一个BytesIO用于字节流。它们跟文件操作配合起来能大幅简化代码逻辑。比如你要对一个字符串做逐行过滤又不想真的生成临时文件直接用StringIO把它包装成“类文件对象”就能复用那套逐行处理逻辑。4. 文件操作的高阶技巧与实用工具推荐4.1 文件锁怎么避免多进程互相打架程序里多进程并发写同一个日志文件或者多个服务实例同时操作同一个配置文件产生的内容互相覆盖这是生产环境常见的问题。Python里常用的文件锁方案有三种。第一种是fcntl模块只在Unix/Linux/macOS上可用。它通过fcntl.flock对文件加排他锁或共享锁import fcntl with open(counter.txt, a) as f: fcntl.flock(f, fcntl.LOCK_EX) f.seek(0) count int(f.read().strip() or 0) count 1 f.seek(0) f.truncate(0) f.write(str(count)) f.flush() fcntl.flock(f, fcntl.LOCK_UN)第二种是Windows上的msvcrt模块功能类似。第三种是借助第三方库filelock它在多个平台上都封装好了接口简单写起来最省心。如果你需要的是跨平台团队协作的可靠性filelock是一个不错的选择。但要注意文件锁只对“商量好都遵守锁协议”的进程有效。如果一个进程根本不加锁就写锁没法阻止它。所以应急措施是所有会并发写同一个文件的进程都统一走同一套加锁逻辑。4.2 文件元数据与状态排查os.stat能告诉你的进阶后你会经常需要查询文件的元数据大小、修改时间、权限、是否是符号链接等。用os.stat可以一次性拿到import os import datetime st os.stat(data.csv) print(f大小: {st.st_size} 字节) print(f修改时间: {datetime.datetime.fromtimestamp(st.st_mtime)})pathlib的Path.stat()也是同样功能但接口更面向对象。我常用它来做清理逻辑找出某个目录下超过30天没动的临时文件并删除。这在日志轮转、缓存清理脚本中很实用。4.3 跨平台要点Windows和Linux的差异清单文件操作跨平台时你需要注意以下几点都是我们实际踩过的路径分隔符Windows是\Linux/macOS是/。永远不要手动拼接分隔符用os.path.join或pathlib.Path。绝对路径的根Windows是盘符C:\Linux是/。判断绝对路径用os.path.isabs别自己想当然。换行符Windows是\r\nLinux/macOS是\n。Python文本模式在读取时会把\r\n自动转换成\n写入时反向转换。如果你需要精确控制换行比如生成给Windows用的文本可以在open()中指定newline或newline\r\n或者使用二进制模式自己处理。文件的编码默认值不同前面已经提到必须显式指定encoding。文件名非法字符Windows不允许:|?*等字符出现在文件名中Linux只不允许/和空字符。写跨平台脚本时生成文件名前最好做个过滤。路径大小写Windows文件系统通常不区分大小写Linux区分。所以Data.txt和data.txt在Windows上可能指向同一个文件在Linux上是两个文件。文件锁fcntl在Windows不可用。4.4 让文件操作更安全的细节习惯聊到这儿想归纳几个让我自己少踩很多坑的习惯算是多年积累的经验总结。第一个习惯重要操作前先备份或先输出预览。比如你要批量重命名文件先打印出修改前后的对照确认无误再执行。涉及覆盖写时先复制一份原文件到临时路径处理成功后再替换。这个习惯救过我太多次。第二个习惯用x模式代替w模式防止意外覆盖。如果你明确要创建新文件且不允许覆盖就用open(..., x)。如果文件已存在它会抛FileExistsError而不会像w一样默默清空。对配置文件、首次初始化场景特别适用。第三个习惯读写前先判断文件是否存在别盲目报错。判断用Path.exists()或os.path.exists但要注意“检查后使用”的竞态问题——文件可能在你检查之后被删掉。所以关键时刻还是要靠try/except捕获FileNotFoundError、PermissionError来兜底。第四个习惯写代码时把可能抛异常的操作放进try/except至少捕获OSError和ValueError。不要只捕获裸Exception那样会掩盖真实问题。5. 常见问题与排查技巧实录5.1 文件明明存在但open()报FileNotFoundError这个问题排第一因为太常见了。主要有几个原因路径拼错相对路径基准不对你以为在/home/user/project目录下实际脚本运行目录是别处文件名有大写或前导空格差异Windows下用了Linux风格路径。排查步骤打印os.getcwd()确认当前工作目录。用Path(path).resolve()看看绝对路径到底是什么。用os.path.exists()去验证文件是否存在。如果路径包含~记得用Path(~).expanduser()展开。一个经验是把相对路径改为基于脚本文件所在目录的路径更可控from pathlib import Path BASE_DIR Path(__file__).resolve().parent target BASE_DIR / data / input.txt这样脚本无论从哪里被调用都能找到相对脚本的路径。5.2 UnicodeDecodeError和UnicodeEncodeError读文件时报UnicodeDecodeError本质是文本字节和指定编码对不上。解决办法在前面已经提到尝试多种编码、使用errorsreplace、带BOM的用utf-8-sig。写文件时报UnicodeEncodeError通常是因为内容里含有目标编码无法表示的字符比如用GBK写一个emoji或生僻字。这时要么统一用utf-8要么在写之前对字符做过滤或转换。我推荐在项目的入口处统一设置默认编码如果你特别想在Windows下全局使用UTF-8可以在代码最顶部设置import sys sys.stdout.reconfigure(encodingutf-8)这只影响标准输出。文件读写还是老老实实逐个指定encoding更稳。5.3 PermissionError: [Errno 13] Permission denied写入一个只读文件或者在Windows下写入已经被Excel打开的文件会报这个错。排查顺序文件是不是只读如果是用os.chmod改权限或者换个输出目录。是否有其他程序占用Windows下尤其常见Excel、编辑器、杀毒软件都可能锁文件。写目录是否有权限检查目录权限位是不是rwx。有时候PermissionError是因为目录不存在比如你想写到/home/user/data/result.txt但data目录不存在。这时先mkdir(parentsTrue, exist_okTrue)。5.4 文件内容写到一半没写完程序正常退出但文件只有一半内容或者退出后文件是空的。原因通常是缓冲区没来得及刷盘。写入重要数据后建议做两件事一是f.flush()把缓冲区的数据推到操作系统二是在必要场景下用os.fsync(f.fileno())让操作系统把数据真正写入磁盘。后者在写数据库文件、关键配置时非常有用但对普通日志不必每次都用因为fsync很慢频繁调用会拖垮性能。with块结束时会自动flush()和close()所以正常情况下数据不会丢。问题是程序在with内崩溃或者被kill -9或者断电那缓冲区里的数据就可能没落盘。这种情况下最好的方案是及时flush并每隔一段时间写一个检查点文件这样即使中途挂了也能从检查点续传。5.5 常见问题排查速查表症状可能原因快速解法文件找不到相对路径基准不对打印os.getcwd()改用基于__file__的绝对路径中文乱码编码不一致统一用encodingutf-8读外源文件尝试utf-8-sig/gbk文件被占用其他进程锁定文件关闭占用程序或者用x模式创建新文件避免冲突文件写一半缓冲区未刷盘flush()后再写关键数据必要时os.fsync()Windows路径报错反斜杠转义用pathlib.Path或原始字符串rC:\path大文件读爆内存一次性read()改用分块读取或for line in f多个进程互相覆盖无锁并发写引入文件锁filelock或fcntl6. 从零到进阶的练习路径与扩展建议6.1 一条可复制的练习路线如果你是从零开始我建议按这个顺序练每一步都动手写几个小脚本。第一步写一个能读取文本文件并统计单词出现次数的脚本。要求用with、指定encoding、输出结果到另一个文件。这一步练的是基础读写。第二步写一个批量重命名工具。把某个文件夹下所有.txt文件按统一规则改成2024-01-01_001.txt这样的格式。要求用pathlib的glob和rename同时打印修改对照表。这一步练的是路径和批量操作。第三步写一个增量日志采集器。定期读取一个持续增长的日志文件末尾新增的数据并写入汇总文件。要求用文件指针定位seek到上次的位置处理文件追加的场景。这一步练的是对文件读写位置的控制。第四步写一个递归目录清理脚本。找出指定目录下所有*.tmp文件并按文件修改时间删除超过30天的旧文件。这一步练的是os.walk和os.stat。第五步给上面的某个脚本加上并发安全的文件写入功能。两个进程同时运行不丢失数据。这一步练的是文件锁。每走一步你会发现之前一步的目标都变成新能力的垫脚石。尤其是第四步和第五步直接决定了你能否在真实生产脚本里游刃有余。6.2 文件操作能延伸到的领域文件操作表面上是基本功但它其实是很多复杂技术的地基。掌握了它你可以轻松上手数据处理与分析读CSV、Excel、JSON等各类数据文件做清洗、转换、合并。日志分析与自动化运维遍历日志目录、解析日志格式、提取错误信息、定时清理。爬虫与数据采集把抓取到的内容落盘成结构化文件按日期分目录存储。Web后台上传下载处理用户上传的临时文件、生成导出文件供下载。配置管理读写配置文件支持多种格式INI、JSON、TOML、YAML。数据库备份与恢复脚本定期导出、压缩、归档、清理旧备份。这些方向用到的核心能力说到底都是“打开文件、读或写、关闭文件、管好路径、处理编码”这几件事。把它们练扎实了后面接触任何框架都会少一层陌生感。6.3 几个被人忽略但很有用的标准库最后分享几个我在文件操作上经常用到的冷门标准库技巧。shutil模块是文件操作的高级封装修copy、move、rmtree这些操作都封装得比os好用。尤其是shutil.move跨文件系统移动文件时是复制删除而不是直接os.rename跨文件系统会报错。shutil.disk_usage可以快速查看磁盘空间写磁盘清理脚本时特别有用。glob模块是文件路径模式匹配的轻量级工具glob.glob(**/*.py, recursiveTrue)可以做递归匹配。虽然pathlib的rglob更好用但有些旧代码库还在用glob你至少要看懂它。fnmatch模块提供了类似文件名通配符的匹配函数比如fnmatch.fnmatch(report_2024.csv, report_*.csv)返回True。用于批量筛选文件名非常直观。gzip模块直接支持读写.gz压缩文件接口和普通文件很接近import gzip with gzip.open(data.txt.gz, wt, encodingutf-8) as f: f.write(压缩内容)如果你的磁盘空间紧张或者要处理上千个日志文件用gzip.open替代open能省下大量空间而代码只差一个模块名。7. 个人经验总结与操作建议我做了多年文件和数据处理相关的工作说实话真正让一个脚本稳定跑几个月的关键从来不是炫酷的API而是一些朴素的习惯。首先明确指定编码。所有你自己生成的文件用UTF-8所有读取的外部文件先确认编码不要赌默认值。我在Windows上被默认GBK坑过太多次后来所有open()都强制带上encoding参数。其次永远使用with管理文件生命周期。这不是风格问题是正确性问题。任何没走close()的路径都可能导致句柄泄漏和数据丢失。虽然Python有垃圾回收机制兜底但依赖它不如严格约束自己。接着路径操作统一走pathlib。不仅代码跨平台而且语义清晰。特别是/运算符拼接路径不仅方便还不会出现连续斜杠或漏斜杠的尴尬问题。再一个写代码前先想好文件失败的模式。文件不存在、没有权限、磁盘满了、编码不对、内容格式不对——这些都是运行时会遇到的事。提前用try/except包住关键操作至少打印出有意义的中文错误提示而不是让堆栈信息淹没在终端里。好的错误提示真的能省大量排查时间。最后批量操作前先做演练。不管是重命名、删除、移动先打印改名前后的对照做一个“dry run”模式。你永远不会想在几百个文件上执行完才发现正则写错了、前缀搞反了、日期格式算错了。这一点我到现在还在坚持而且每次都能避免误操作。文件操作看起来基础但它是所有数据工作的起点。好好打磨这些细节以后的脚本会越来越稳。希望这篇文章能帮你少走一些弯路。