Python脚本自动整理下载目录：从需求分析到定时任务配置的完整实战

我有个持续了很久的“坏习惯”：每天都在往电脑同一个文件夹里丢文件，报表、截图、压缩包、安装包、临时导出的 CSV，全都堆在下载目录里。平时不觉得有什么，等真要找某个文件的时候，对着那几百条混乱的记录一页一页翻，心态一下子就崩了。

真正让我下决心写 Python 脚本的，是某天早晨。有条消息催一份合同扫描件，我打开下载目录，滚了五六遍鼠标才找到，文件名是“20250326_143302.jpg”——一个毫无意义的截图时间戳。那个文件夹里的 60 多个文件，全以这种姿态挤在一起。我知道，不能再靠手动整理了。

我的方案很朴素：用 Python 写一个脚本，把这些文件按类型自动分到不同文件夹。动手前我以为半小时就能搞定，结果从第一版到最后稳定运行，陆续改了五六轮。回头来看，驱动这个脚本诞生的过程中，最值钱的不是那几十行代码，而是整个“从需求到可运行”的思考路径。所以我把这个过程完整写下来，从需求分析、规则设计、代码实现，到定时任务配置和踩坑记录都覆盖到。它能直接解决 90% 的文件整理烦恼，而其中“遍历、判断、执行、反馈”的思路，也能平移到其他重复性劳动上。

1. 需求分析：先弄明白这个脚本要解决什么

1.1 用一句话说清痛点，再用三个问题问透需求

在动手写任何代码之前，我都会先做一件事：把一个模糊的“我想让电脑不乱”的念头，拆成具体且可回答的问题。因为写脚本最怕的不是语法错，而是需求模糊。需求不清，写出来的东西要么过度设计，要么根本解决不了真正的问题。

这次的三个问题是：这些文件是怎么产生的？它们现在在哪？我期望它们最终变成什么样？

先回答第一个。我下载目录里的文件来源大概有四种：截图软件自动生成的图片、同事发来的各种文档、从网上拉下来的安装包、开发测试时导出的临时数据文件。不同的来源，决定了后续文件的集中度和命名习惯。比如截图软件命名可能是时间戳，同事发的文档可能叫“最终版v3”，安装包可能带版本号。来源搞清楚之后，你才能预测“会遇到哪些奇怪文件名”。

第二个问题更简单：所有文件都在同一个下载目录。这意味着脚本只需要处理一个根目录，不需要跨磁盘、不需要复杂路径跳转，第一版可以做得非常轻。

第三个问题决定了最终交付物。我期望的状态是：图片进图片文件夹，文档进文档文件夹，压缩包进压缩包文件夹。如果遇到实在无法判别的文件，单独放进“未分类”文件夹，不阻塞整体流程。这个目标可以量化：运行完脚本后，根目录只剩下分类文件夹，里面的文件数量总和等于之前的总数，不丢一个。

还有一个关键决策：识别文件类型只看扩展名，不检查内容。为什么？因为按内容识别文件类型的代价太高了，你需要读取文件头，甚至对不同格式写不同的解析逻辑。而对日常整理来说，扩展名已经能覆盖绝大多数情况——PDF 就是 PDF，JPG 就是 JPG，绝大多数软件保存文件时都会带上正确的扩展名。用扩展名做快速判断，性价比最高。虽然会有个别文件扩展名是错的，但那是少数，不值得为了它们把脚本搞重。

1.2 为什么选 Python，而不是直接下载一个整理工具

提到整理文件，很多人的第一反应是“现成的整理工具不就行了吗”。确实，市面上有那种按规则自动归类文件的软件，Windows 自带的库功能也能按文件类型分组显示。但对我来说，这几个方案都有明显短板。

Windows 的“分组”功能，本质上只是把文件按类型分组显示，它不改变文件的物理位置。也就是说，你看到的“整齐”只是视觉上的，文件还是在同一个目录里混着。如果你需要把文件打包带走、需要让其他软件只能扫描某个文件夹，这一步视觉分组就帮不上忙。

现成的整理工具倒是能移动文件，但规则是别人设计好的，想加一个“文件名含‘合同’就单独放进合同文件夹”的规则，不一定能实现。而且这类工具多多少少带云端同步、自动更新这些我不需要的功能，明明只想本地整理，却要接受一堆无关的东西。

选择 Python 的理由很直接：第一，它有 pathlib 和 shutil 两个标准库，处理文件移动这件事零依赖，不需要安装任何第三方包；第二，规则完全自己掌控，今天想按扩展名分，明天想按日期分，改几行代码就行；第三，这个脚本不仅是解决一个问题，更是给自己积累一个“自动化的通用套路”，后面做备份、清理、批量重命名都能复用同一套逻辑。

我做一个简单对比：

2. 动手写代码前，先把设计问题想清楚

2.1 分类规则：用字典把“扩展名”映射到“文件夹”

写脚本前最重要的一步，是定义清楚规则。这个脚本的核心规则只有一条：扩展名属于哪个分类，文件就进哪个文件夹。

我选择用 Python 字典来表达这条规则，键是分类名，值是扩展名列表：

EXT_MAP = { '图片': ['.jpg', '.jpeg', '.png', '.gif', '.bmp', '.svg', '.webp'], '文档': ['.doc', '.docx', '.pdf', '.txt', '.xls', '.xlsx', '.ppt', '.pptx', '.md', '.csv'], '压缩包': ['.zip', '.rar', '.7z', '.tar', '.gz'], '代码': ['.py', '.js', '.ts', '.html', '.css', '.json', '.xml', '.sql', '.sh'], '视频': ['.mp4', '.avi', '.mkv', '.mov', '.wmv'], '音频': ['.mp3', '.wav', '.flac', '.aac'], '安装包': ['.exe', '.msi', '.dmg', '.pkg'], }

字典结构有两个明显好处。一是规则集中在一个地方，以后想加一个“字体”分类，只需要加一行键值对；二是字典的键天然可以作为目标文件夹的名字，省去了另做映射的功夫。分类之间尽量不要有重叠扩展名，否则字典遍历时永远命中先被遍历到的那一个，容易让人困惑。

不要试图在第一版就把分类做得特别细。“图片”和“文档”这种大分类就够了，等脚本跑起来后，你再观察哪类文件多、有进一步拆分的必要，再迭代。一上来就搞一两百个分类，反而会让你在配置上花掉大量时间，核心逻辑却没跑通。我第一版只分了五类，后面根据实际使用情况才慢慢加。

2.2 标准库选型：认准 pathlib 和 shutil

选择处理文件的库，我几乎没有犹豫，直接用了 pathlib 和 shutil。这里想多说一句为什么不用裸的 os.path，因为它值得讲清楚。

以前用os.path.join()拼接路径时，最头痛的就是跨平台分隔符问题。Windows 路径分隔符是反斜杠，macOS/Linux 是正斜杠。如果你在代码里写死某个分隔符，换一台系统就跑不起来。pathlib 把路径当作对象处理，用/运算符合并路径，底层会自动适配当前系统的路径规则。写一次，到处跑，这种省心是真实存在的。

举个例子：

from pathlib import Path # 不推荐：手动拼字符串，换系统容易出问题 # path = 'C:/Users/xxx/Downloads' + '/' + '图片' # 推荐：Path 对象直接用 / 拼接 base = Path('C:/Users/xxx/Downloads') pic_dir = base / '图片'

shutil 是标准库里的“高级文件操作”工具箱，移动文件用shutil.move()。你可能会问，os.rename()也能移动文件，为什么非要用 shutil？区别在于，os.rename()在跨设备移动时会失败——比如把文件从 C 盘移到 D 盘，两个盘符对应不同的存储设备，os.rename()直接抛跨设备异常，而shutil.move()会先尝试重命名，不行就自动改成复制加删除，帮你把这种边界情况兜住。日常整理脚本要处理的正是这种不确定性，所以选 shutil 更稳妥。

2.3 预演一遍边界情况，心里有数再动手

好代码的标准不是主流程走得有多顺，而是异常来临时依然稳定。写第一行代码之前，我把可能遇到的情况在脑子里过了一遍：

• 源文件夹不存在怎么办？
• 文件夹里一个文件都没有怎么办？
• 文件名以点开头（比如.env）怎么办？
• 目标文件夹里已经有同名的文件怎么办？
• 文件正被其他程序占用怎么办？
• 扩展名不在映射表里怎么办？

这些情况不需要在第一版全部解决，但至少要有个预案。因为在实际运行中它们真的都会出现，尤其是重名和文件占用，几乎每跑一次脚本就可能遇到一个。

把边界情况想清楚还有一个额外价值：它会影响你的数据结构和代码结构。比如决定用“未分类”文件夹兜底，就意味字典遍历完之后还要有return '未分类'语句；决定重名自动加序号，就意味每个文件的目标路径都要经过一个独立函数计算。这些决策都是先于代码存在的，等到写代码时不过是按设计图施工罢了。

3. 第一版脚本的诞生：遍历、分类、移动

3.1 第一步：先用十行代码假装自己是“目录侦查员”

任何文件整理脚本，第一步永远是遍历目录。这个阶段的目标很简单：把目标文件夹下所有文件的名字和扩展名打印出来。先不做任何移动操作，因为你要确认脚本看到的目录，和你以为的目录是一致的。

第一版代码长这样：

from pathlib import Path source = Path(r'C:\Users\你的用户名\Downloads') for item in source.iterdir(): if item.is_file(): print(item.name, '->', item.suffix)

这段代码里有个细节值得留意。如果套用os.listdir()，拿到的就只是字符串，还要再通过os.path.isfile()判断文件还是文件夹。而Path.iterdir()直接返回Path对象，每个对象自带is_file()、is_dir()、suffix属性，少写不少辅助代码。这也是我在新项目里尽量用 pathlib 的原因。

跑完这一步，我得到了一个与预想一致的输出：图片占了大头，文档次之，还有一些奇怪扩展名文件。这个简单的“目录侦查”脚本是后面所有步骤的地基，后续只是在它上面加判断、加动作而已。

3.2 第二步：写出 get_category 分类函数

遍历解决了“看见文件”的问题，接下来要解决“识别类型”的问题。我把分类逻辑单独抽成一个函数，不揉进主循环，是因为它是整个脚本里最容易被反复修改的部分——今天加个“音频”分类，明天拆一个“文档”子类，独立函数让改动影响最小。

分类函数实现非常简单：

def get_category(filename: str) -> str: ext = Path(filename).suffix.lower() for category, exts in EXT_MAP.items(): if ext in exts: return category return '未分类'

逻辑是：拿到文件后缀，转成小写，遍历字典找到所属分类，找不到就返回“未分类”。这里有一个教训是“后缀先转小写再匹配”。因为实际文件的后缀可能大写、小写或大小写混合，而字典里写的是统一的.PDF这种样式，不转小写，一个.PDF文件就可能落入“未分类”。这个小问题排查起来容易让人崩溃，因为肉眼很难看出哪里有大小写差异。

函数写完后，我顺手把主循环里加了一行打印category，测试了几个真实文件，确认分类结果符合预期，才继续下一步。每写一小步就跑一次，是避免脚本“写完就翻车”的好习惯。

3.3 第三步：移动文件，让目录真的变整齐

分类函数就绪后，就可以加入“移动”这个真正的动作了。我先实现了最简版本，不加任何保护逻辑，因为要先把主流程跑通：

import shutil from pathlib import Path def organize_folder(source: str): src = Path(source) if not src.exists() or not src.is_dir(): print(f'路径不存在或不是文件夹: {source}') return for item in src.iterdir(): if item.is_dir(): continue category = get_category(item.name) dest_dir = src / category dest_dir.mkdir(exist_ok=True) shutil.move(str(item), str(dest_dir / item.name)) print(f'已移动: {item.name} -> {category}')

这段代码里几个决定需要说清楚。用item.is_dir()跳过子文件夹，是因为分类文件夹本身也在根目录里，如果你不跳过文件夹，脚本就会试图把“图片”文件夹移动到“图片”文件夹里，逻辑直接乱掉。用mkdir(exist_ok=True)让分类文件夹自动创建，省去了预先手工建目录的步骤。移动前后各打印一行，不是为了仪式感，而是让运行后能对照日志确认每个文件的去向。

我手动运行了这个版本，看着终端里滚过一串“已移动”，下载目录从“杂物间”变成了有分类的“档案室”，那一刻的成就感是真实的。但很快我就发现了必须解决的问题：当“文档”文件夹里已经有一个report.pdf，而来一个同名的report.pdf时，shutil.move()会直接抛异常，脚本中断，后面的文件一个都处理不了。

3.4 把第一版完整脚本组装起来

让我把目前能工作的部分拼成一个完整脚本，功能是：遍历目录、判断分类、自动创建文件夹、移动文件并打印日志。这个版本是整个脚本的地基，后续所有增强都是在这个基础上叠加。写成完整形式如下：

from pathlib import Path import shutil EXT_MAP = { '图片': ['.jpg', '.jpeg', '.png', '.gif', '.bmp', '.svg', '.webp'], '文档': ['.doc', '.docx', '.pdf', '.txt', '.xls', '.xlsx', '.ppt', '.pptx', '.md', '.csv'], '压缩包': ['.zip', '.rar', '.7z', '.tar', '.gz'], '代码': ['.py', '.js', '.ts', '.html', '.css', '.json', '.xml', '.sql', '.sh'], '视频': ['.mp4', '.avi', '.mkv', '.mov', '.wmv'], '音频': ['.mp3', '.wav', '.flac', '.aac'], '安装包': ['.exe', '.msi', '.dmg', '.pkg'], } def get_category(filename: str) -> str: ext = Path(filename).suffix.lower() for category, exts in EXT_MAP.items(): if ext in exts: return category return '未分类' def organize_folder(source: str): src = Path(source) if not src.exists() or not src.is_dir(): print(f'路径不存在或不是文件夹: {source}') return for item in src.iterdir(): if item.is_dir(): continue category = get_category(item.name) dest_dir = src / category dest_dir.mkdir(exist_ok=True) shutil.move(str(item), str(dest_dir / item.name)) print(f'已移动: {item.name} -> {category}') if __name__ == '__main__': organize_folder(r'C:\Users\你的用户名\Downloads')

放在__main__下面执行，是为了将来把脚本模块化时，其他文件import它不会触发生成函数体里的代码。这算是一个很小的工程习惯，但对代码的整洁性帮助不小。

4. 从“能跑”到“好用”：补上重名、未知类型和安全开关

4.1 重名文件自动加序号，让脚本不中断

重名文件的处理，是文件整理脚本里最基础也最必要的功能。不处理的后果很直接：shutil.move()抛异常，脚本中断，后半截文件一个都整理不到。我第一版就栽在这上面，之后老老实实加了逻辑。

实现逻辑不复杂：先拼接目标路径，如果发现该路径已存在，就在文件名和扩展名之间加_1，如果_1也存在，就换_2，直到找到一个不冲突的名字。

def unique_dest(dest_dir: Path, filename: str) -> Path: target = dest_dir / filename if not target.exists(): return target stem = Path(filename).stem suffix = Path(filename).suffix counter = 1 while True: candidate = dest_dir / f'{stem}_{counter}{suffix}' if not candidate.exists(): return candidate counter += 1

一个细节值得强调：重名检测用Path.exists()而不是Path.is_file()。因为目标路径如果恰好被同名文件夹占用，exists()返回 True，能正确触发加序号逻辑；如果用is_file()，遇到同名文件夹就返回 False，可能导致错误覆盖或移动异常。在这种“判断存在性”的场景里，用更保守的判断永远是更稳妥的。加入这个函数后，移动那行代码就变成：

target = unique_dest(dest_dir, item.name) shutil.move(str(item), str(target))

4.2 未知扩展名放进“未分类”，临时文件直接忽略

运行一段时间后会发现，下载目录里总会有一些“来路不明”的文件。比如扩展名不在映射表里的，甚至完全没有后缀的文件。我的处理策略是集中放入“未分类”文件夹，而不是让脚本报错。这样一来，整理流程不会中断，未知文件也不会散落在根目录，等有空时再手动翻一下“未分类”，该处理的处理，该删的删。

但有一类情况需要单独区分：临时文件和下载未完成的文件。它们的特点是扩展名很特殊，比如.crdownload（浏览器下载未完成）、.part（下载工具临时分段文件）、.tmp（临时文件）。这些文件有个共同风险：如果脚本在下载进行中强行移动它们，可能把下载一半的文件挪走，导致下载程序找不到目标文件，最终下载失败。所以我后来给脚本加了一个忽略列表：

IGNORE_EXTS = {'.crdownload', '.part', '.tmp', '.temp', '.lnk'} # 在循环里加一个判断 if item.suffix.lower() in IGNORE_EXTS: print(f'忽略临时文件: {item.name}') continue

严格来说，.lnk不是临时文件，而是 Windows 快捷方式的扩展名。我把它也放进忽略列表，是因为快捷方式本身只是个引用，移动它意义不大，反而容易造成桌面快捷方式失效。这种取舍没有统一答案，完全看你的使用场景，但如果遇到迟疑，让脚本“不处理”通常是更安全的选择。

4.3 dry-run 模式：正式执行前先在脑内彩排一遍

这是整个脚本里性价比最高的一项功能。所谓 dry-run，就是只模拟一遍整理流程，打印出“如果运行会怎么移动”，但不真正动文件。它的价值在你刚写完新规则、不确定会不会弄乱目录时体现得淋漓尽致。

实现起来非常简单，加一个布尔参数控制是否真正执行shutil.move()就行：

def organize_folder(source: str, dry_run: bool = True): ... if dry_run: print(f'[模拟] 将移动: {item.name} -> {category}/{target.name}') else: shutil.move(str(item), str(target)) print(f'已移动: {item.name} -> {category}/{target.name}')

我把默认值设为 True。也就是说，你刚写完脚本直接运行时，它只会告诉你“会怎么移动”，而不会真的移动任何文件。等你仔细看完输出，确认规则符合预期，再指定dry_run=False执行真正的整理。这个习惯后来被我用到了所有涉及文件操作的脚本里。对于“高破坏性”的自动化任务，比如批量删除、批量覆盖，一个“先打印后执行”的开关能让你少很多提心吊胆的时刻。

5. 让它到点自己跑：定时任务配置实录

5.1 Windows 任务计划程序，这样配才稳

脚本写好了，不代表自动化结束。如果每次还要手动打开终端执行，那充其量算“半自动”。真正的自动化是让系统到点自己运行脚本。

Windows 上用自带的任务计划程序就能实现。我以“每周五下午 5 点自动整理下载目录”为例，配置步骤大致如下：

1. 打开“任务计划程序”，右侧点击“创建基本任务”
2. 触发器选择“每周”，勾选星期五，时间设成 17:00
3. 操作选择“启动程序”，程序填 Python 解释器的完整路径，比如C:\Python312\python.exe
4. “添加参数”填脚本的完整路径，比如C:\scripts\organize.py
5. 在“起始于”中填脚本所在目录C:\scripts

第五步非常容易被忽略，但不填的话，脚本里所有依赖相对路径的操作都可能出错。另外，程序路径不要直接填python，因为任务计划程序经常读不到你在命令行里配置的 PATH 环境变量，填解释器的绝对路径是最稳的。最后在“条件”选项卡里勾选“唤醒计算机以运行此任务”，否则电脑睡眠时任务不会执行。

5.2 macOS/Linux 用 cron，一行命令搞定

在 macOS 和 Linux 上，定时任务的经典工具是 cron。在终端运行crontab -e打开当前用户的定时任务配置，然后写一行：

30 17 * * 5 cd /path/to/script && /usr/bin/python3 /path/to/script/organize.py

这行的意思是“每周五 17:30 执行一次，先切换到脚本目录，再让 Python 运行脚本”。前五个字段分别是分、时、日、月、星期几。*表示任意值，5代表周五。如果想每天执行，把最后的5改成*。

有一个坑很隐蔽：cron 的环境变量和登录终端的环境变量并不一致。比如你在终端里用的 Python 是某个路径，在 cron 里直接写python3可能解析到完全不同的解释器。如果脚本依赖第三方库，还会出现明明 pip 已经安装了，cron 里却报缺模块的情况。解决办法有几个，最稳妥的是在 cron 行里写 Python 解释器的绝对路径，或者在脚本开头手动处理sys.path。我这个脚本只用标准库，所以这些坑暂时没踩到，但如果你后续把脚本做复杂了，大概率会遇到，提前打个预防针。

5.3 日志输出：自动化也要“留底”

脚本没有人盯着跑的时候，打印到终端的信息就没什么意义了——因为终端窗口可能早就关了。为了后续能核对运行情况，最好把运行结果写入日志文件。

最简单的做法是脚本末尾追加一行记录：

from datetime import datetime with open('organize_log.txt', 'a', encoding='utf-8') as f: f.write(f'{datetime.now().strftime("%Y-%m-%d %H:%M:%S")} 完成整理\n')

日志不一定要很复杂，一行时间戳加结果就够了。它的价值在几天后体现：当你发现下载目录里多了几个漏网之鱼，打开日志一看，原来那天有几个文件因为占用移动失败，就能快速定位问题。如果连日志都没有，就只能靠“猜”了。我现在养成的习惯是：凡是定时跑的脚本，最后一句必须写日志，没商量。

6. 正式运行后踩到的坑与排查思路

6.1 文件被占用导致中断，加异常处理

我第一次把脚本接进定时任务，第二天早上查日志就发现它在半夜 0 点挂了。原因很直接：有一个文件正被某个程序占用，Windows 不允许移动它，shutil.move()抛出了权限异常。

直接的处理方式是在移动操作外包一层异常捕获：

try: shutil.move(str(item), str(target)) print(f'已移动: {item.name} -> {category}/{target.name}') except Exception as e: print(f'移动失败: {item.name}，原因: {e}')

这样单个文件失败不会中断整个脚本，其他文件仍然正常整理。失败的文件留在原目录里，后续再看原因。这次的教训是：写文件操作脚本时，永远默认文件世界充满意外，被占用、权限不足、磁盘已满，突发事件层出不穷。脚本的任务是把能处理的处理好，不能处理的记录下来留给人去决策，这是更符合现实的做法。

6.2 中文文件名打印乱码，怎么处理

第二个常见问题是打印中文文件名时出现乱码。这里先澄清一点：乱码通常只出现在“打印”环节，不影响文件实际移动。因为 Python 3 内部字符串默认是 Unicode，文件操作库也处理好了编码问题。乱码主要是终端显示问题。

Windows 终端默认编码是老旧的 GBK 或当前区域设置，脚本打印 UTF-8 中文时两端不一致，就产生乱码。解决方式有两种：

import sys sys.stdout.reconfigure(encoding='utf-8')

在脚本最开头加上这行，强制标准输出使用 UTF-8。或者运行脚本前，在终端执行chcp 65001切换终端代码页。我遇到过更微妙的情况：文件名字符本身是某些生僻字或特殊符号，打印时正常，移动时却报错，这通常和文件系统或远程目录的字符支持有关。遇到这种个例，直接手动处理最省心。

6.3 点开头文件与隐藏文件，单列规则

第三个坑和点开头文件有关。在 macOS 和 Linux 上，以点开头的文件默认是隐藏文件，比如.bashrc、.gitignore。按扩展名分类时，.gitignore没有扩展名，会掉进“未分类”；.env.local按扩展名看像是.local，实际它的身份是环境配置文件。两种情况都不理想。

我的选择是跳过隐藏文件，在循环里加个判断：

if item.name.startswith('.'): print(f'跳过隐藏文件: {item.name}') continue

这个选择基于一个原则：整理下载目录的目的是让常用文件更好找，而隐藏文件通常是配置文件，平时不直接使用，留在原地不影响整体整洁。当然如果你的下载目录里有需要归档的.gitignore，也可以改成放进专门文件夹，这完全按个人偏好决定。关键是这类文件要有一条明确的路，而不是掉进“未分类”被遗忘。

6.4 常见问题速查表

把零散的问题整理成一张表，方便你以后快速对照：

7. 后续扩展：一个脚本如何长成一套自动化方案

7.1 把规则抽成 JSON 配置文件

脚本稳定运行一些时日后，第一个值得做的升级是把EXT_MAP的分类规则抽成独立的 JSON 配置文件。这样即使完全不懂代码的人，也可以打开 JSON 文件调整分类——想新增“合同”分类，就往文档分类里加几个扩展名，或直接新建一个键。

配置文件长这样：

{ "图片": [".jpg", ".jpeg", ".png"], "文档": [".pdf", ".docx", ".txt"] }

脚本读取配置只要几行：

import json with open('rules.json', 'r', encoding='utf-8') as f: EXT_MAP = json.load(f)

从“写死”到“配置化”是很重要的一次思路转变。你会发现，任何脚本都可以把“规则”和“逻辑”分离：规则交给用户配置，逻辑留在代码里。这样做的好处不只是易维护，更重要的是让脚本有了被更多人使用的可能。这件事也让我体会到，一个工具的生命力，往往取决于它的定制门槛有多低。

7.2 从整理文件到任意重复劳动的通用套路

文件整理只是自动化的一个入口。当你掌握了“遍历 → 判断 → 执行 → 反馈 → 记录”这个循环之后，可以做的事情会越来越多。我后来基于同一种套路做过几个小脚本：批量给照片按照拍摄日期重命名、把七天前的临时文件自动清理掉、把某个目录下新修改的文件增量备份到移动硬盘里。

这些任务本质上都没有脱离文件整理脚本的五个环节：

1. 遍历：拿到所有待处理对象
2. 判断：决定每个对象该走哪条路
3. 执行：真正执行移动、改名、复制、删除
4. 反馈：打印当前处理结果
5. 记录：留下日志供事后追溯

遇到新自动化需求时，我会先套这套框架想五分钟，看看哪里需要改，哪里可以复用。大多数情况下，只是换了“执行”那一步的内容，整个框架可以直接搬过去。这就是“做一个脚本”比“解决一个问题”更值钱的原因。

7.3 我最大的收获：掌控感

写这个脚本之前，我也经历过“有现成工具绝不动手”的阶段。但真正自己写一次之后，最大的收获并不是省下的那点整理时间，而是对整个工作流有了掌控感。我知道每个文件去了哪里，知道遇到什么情况脚本会怎么处理，出现问题时能看懂日志去修。这种掌控感是现成工具很难给我的。

如果你也想开始玩自动化，不要一上来就写个大项目。就从你每天重复三次以上的小动作开始，先写一个只打印目录的脚本，再加判断，再加操作，再加定时。一步步来，你会和我一样发现，一个脚本的诞生，其实就是把一件小事做到极致的过程。