1. 三年没动的下载文件夹，到底是怎么堆成一座垃圾山的
我那个下载文件夹，最后一次认真整理大概是在三年前的某个周末。之后它就进入了"只进不出"的状态：装上新的浏览器、换过两次电脑、迁移过一盘数据，唯一没变的就是它。直到上个月我要找一个两年前下载的报价模板，翻了二十分钟没找到，才决定动手。那一刻的实际数字是：4193 个文件、37.6 GB、最老的一个文件创建于 2021 年 3 月，最新的是三分钟前刚下载的一张发票截图。
这个体积本身不吓人，吓人的是结构。里面有 11 个同名的安装包.exe，被系统自动加上了(1)到(10)的后缀；有 4 份完全一样的 PDF，各自躺在不同的子目录里；有 60 多个只有几十 KB 的无效下载，是当年网速不稳时中断留下的残片；还有一批名字是未命名文档.docx、新建文件夹 (3)这种连自己都认不出来的东西。真正让我崩溃的不是"文件多"，而是每次打开它都要重新做一遍决策——这个能不能删？那个是不是还要用？想三秒钟，关掉窗口，继续拖。
1.1 拖延的根源不是懒，是每次决策的成本太高
我后来复盘过这件事，得到的结论有点反直觉：整理下载文件夹之所以一拖三年，不是因为懒，而是因为这是一件决策密度极高的任务。一个正常的工作任务，你花两小时能有明确产出；而整理 4000 个文件，意味着你要做 4000 次"留还是删、放哪、叫什么名"的微决策，每次决策 3 到 5 秒，加起来就是四五个小时纯认知消耗，而且中间不能分心，一分心就得从头再判断一遍文件之间的重复关系。
注意：任何"一次性手动整理干净"的计划，本质上是要求你在某一个下午保持四五个小时的高质量注意力。这个前提几乎不可能成立，所以计划必然破产。
我做过一个粗糙的统计：这 4193 个文件里，有 2890 个（约 69%）从下载完成之后再也没被打开过；有 512 个是同一份文件的重复下载；真正在最近一年内被访问过的，不到 400 个。也就是说，用 400 个文件的价值，拖着 3800 个文件的认知负担。这就是典型的"入口没有闸门"——所有东西默认掉进同一个平面目录，时间一长必然变成垃圾场。
1.2 我给自己定下的三条硬标准：本地、无损、可回滚
在动手之前我先立了三条规矩，后来的所有工具选择都是围绕这三条来的。
第一是本地。我要处理的东西里有合同扫描件、财务表格、还有一些体积上到几个 GB 的素材包。这些文件不适合上传到任何在线服务再处理一遍，一方面几个 GB 的上传本身就要等很久，另一方面我完全不想让这些东西离开本机硬盘。本地工具直接读磁盘，速度是磁盘读写的速度，不受网络影响。
第二是无损。任何批量操作在执行前必须给我一份完整的预览清单，告诉我"哪 312 个文件将被移动，从哪到哪"，我确认之后才真正执行。绝对不允许出现"点一下按钮，工具自己判断完就动手"的设计，因为工具的判断逻辑不可能覆盖所有边界情况。
第三是可回滚。所有移动、重命名操作必须留一份操作日志，能一键撤销上一次操作。这条听起来像保险，实际上救了我两次——后面会细讲。
这三条标准定下来之后，选型范围一下子窄了很多。市面上大部分"整理工具"要么是云端在线转换类（违反第一条），要么是"一键智能归档"黑盒（违反第二、三条），真正符合的，是那种规则引擎加本地索引的思路。
2. 选型：什么样的本地整理工具才值得留在电脑里
三年没打开过下载文件夹的人，其实不缺工具，缺的是一个你愿意每天点开看一眼的工具。这听起来像是废话，但它是选型的核心。我删掉过好几个功能很齐全的整理软件，原因很朴素：界面难看，扫描 4000 个文件卡成幻灯片，用两次就不想再打开第三次。
2.1 在线服务和本地工具的分水岭在哪
先说清楚一个界限。有一类工具是"你把文件传上去，我在云端帮你分类去重，再让你下回来"。这类方案在处理小文件（几十 MB 的图片、文档）时体验还行，但一旦碰上几个 GB 的东西就完全失效——上传要等，下载要等，中间还多出一份副本占空间，更要紧的是这些东西根本不该离开本机。另一类是本地扫描 + 本地规则 + 本地索引，工具本身只做三件事：读磁盘元数据、按你的规则算出结果、在你确认后执行文件操作。这两类的差别不在于功能多少，而在于数据流向。
| 维度 | 云端处理类 | 本地规则引擎类 |
|---|---|---|
| 大文件（GB 级） | 基本不可用 | 受磁盘速度限制，可用 |
| 隐私敏感文件 | 需上传，风险高 | 全程不出本机 |
| 扫描 4000 文件耗时 | 取决于上传带宽 | 元数据扫描通常 10 秒内 |
| 断网能否使用 | 不能 | 完全可用 |
| 撤销与日志 | 通常没有 | 是必备能力 |
2.2 颜值不是虚荣，它直接决定使用频次
我必须为"颜值"这件事说句公道话。整理工具和代码编辑器不一样，前者是低频但需要反复打开的工具，你会在半年里打开它二三十次。如果它的列表滚动一下要卡两秒，缩略图加载不出来，配色刺眼，那你的心理成本会高到宁可继续拖着。设计良好的工具有几个共同的细节：
- 列表虚拟化。4000 个文件同时渲染成 4000 个 DOM 节点，必然卡顿。好的实现只渲染当前视口里的那二三十行，滚动时动态替换内容。你在界面上感受到的"丝滑"，本质上就是这个机制在起作用。
- 缩略图按需加载且有缓存。图片和视频的缩略图生成是有成本的，第一次扫描时生成并落盘缓存，第二次打开就是秒开。如果每次都要重新生成，体验立刻崩。
- 键盘优先的操作流。整理过程中你的手不该离开键盘：上下移动、空格预览、D 标记删除、M 标记移动、Ctrl+Z 撤销。鼠标一次一次点右键菜单，效率会掉一半以上。
- 深色模式与低饱和配色。这个纯粹是主观偏好，但我实测下来，长时间盯着文件列表时，低饱和的界面确实不容易疲劳。
2.3 我的选型检查表
我把三年里用过的工具和最后留下的那一套，按能力项列了个清单。你可以拿这张表去对照你手上的工具，缺三项以上的基本可以放弃了。
| 能力项 | 为什么必须有 | 缺失的后果 |
|---|---|---|
| 规则引擎（扩展名/时间/大小/路径） | 分类逻辑要能自己定义 | 只能用它预设的几类，遇特殊情况就废 |
| 执行前预览清单 | 批量操作必须可控 | 一次误操作几千个文件，无法收拾 |
| 操作日志与撤销 | 给错误留后路 | 出错只能靠备份，没有备份就完蛋 |
| 内容哈希去重 | 文件名不可信 | 只能靠文件名判断重复，漏掉大量真重复 |
| 本地文件名索引 | 整理完之后能秒搜 | 还是要用系统搜索，慢且结果乱 |
| 批量重命名 + 模板 | 让文件名本身可检索 | 整理完还是靠记忆找文件 |
| 待定/暂存区机制 | 处理"拿不准"的文件 | 要么乱删，要么又堆成一坨 |
| 定时巡检 | 防止重新变乱 | 三个月后回到原点 |
这张表里，我最想强调的不是哈希去重，也不是索引，而是待定区和撤销这两项。它们是"心理层面的基础设施"——正是因为有这两样，我才敢在第一轮就大胆处理 4000 个文件。
3. 第一次清理的完整流程：先扫描，再决策，最后才动手
动手那天的顺序非常重要，我踩过的最大坑就是"边看边整理"——看到一个文件就决定它去哪，看了一百个之后规则已经开始漂移了，前面分到"素材"目录的，后面可能分到"图片"目录去了。正确的做法是把决策和执行彻底分开。
3.1 第一步永远是只读扫描，生成一份完整清单
这一步不做任何修改，只读元数据，把结果导出成一份 CSV。为什么要导出成 CSV 而不是直接在工具里看？因为 CSV 能排序、能筛选、能用表格公式统计，你能在动手之前就看清楚整个盘子的全貌。我用的扫描脚本大致是这样：
import csv from pathlib import Path root = Path.home() / "Downloads" rows = [] for p in root.rglob("*"): if not p.is_file(): continue st = p.stat() rows.append({ "name": p.name, "path": str(p), "size": st.st_size, "mtime": int(st.st_mtime), "ext": p.suffix.lower(), }) with open("scan.csv", "w", newline="", encoding="utf-8-sig") as f: w = csv.DictWriter(f, fieldnames=["name", "path", "size", "mtime", "ext"]) w.writeheader() w.writerows(rows) print("files:", len(rows), "total MB:", sum(r["size"] for r in rows) // 1048576)四千个文件的元数据扫描，在本机 SSD 上跑了 4 秒左右。这份 CSV 打开之后，我做的第一件事不是分类，而是按扩展名分组计数。结果很说明问题：.exe和.dmg一共 214 个（安装包），.zip和.7z一共 189 个（压缩包），.jpg/.png一共 1687 个（图片），.pdf216 个（文档），剩下的长尾全是各种零碎。图片占了四成以上，这是我完全没预料到的——平时截图、保存的表情包、从网页另存的小图，全掉进来了。
提示：扫描阶段一定要把
mtime存成整数时间戳，后面做时间分桶的时候比字符串方便得多。
3.2 分类的三个维度：扩展名、时间、来源
只用扩展名分类是不够的，因为同一个扩展名下可能是完全不同的东西。一个.zip可能是某个软件的绿色版压缩包（该进"安装包"），也可能是我下载的一套图标素材（该进"素材"）。所以我用了三个维度叠加：
- 扩展名：决定大类，比如
.pdf/.docx/.xlsx归到文档，.mp4/.mkv归到影音。 - 修改时间：决定分区。我的做法是按"最近 90 天"和"90 天以前"切开，最近的留在浅层目录随手可取，老的沉到归档目录去。
- 来源线索：浏览器下载的文件，文件名里往往留着站点的痕迹，比如带
_2024之类的日期后缀，或者带setup、installer、portable这类词。这些线索不足以做精确判断，但足够把明显的安装包挑出来。
我把这三个维度组合成一套规则表，大概是这样的：
| 匹配条件 | 目标目录 | 说明 |
|---|---|---|
| 名称含 setup/install/portable 或扩展名为 exe/dmg/msi | 归档/安装包 | 装完基本不会再用的东西 |
| 扩展名 jpg/png/gif/webp 且大小 < 2MB | 归档/图片/截图 | 截图和小图单独放 |
| 扩展名 jpg/png/psd/ai 且大小 > 20MB | 素材/设计 | 大图多半是设计素材 |
| 扩展名 pdf/docx/xlsx/pptx | 文档 | 再按年份细分 |
| 扩展名 zip/7z/rar | 归档/压缩包 | 单独放，方便统一解压清理 |
| 不匹配以上任何一条，或拿不准 | 待定区 | 重点机制，下面细讲 |
3.3 重名冲突：不要覆盖，也别无脑加序号
这是我这次最得意的一个改进。三年里下载文件夹里堆了 11 个同名的安装包，文件名从xxx.exe一直到xxx(10).exe。传统的处理方式是"遇到重名就加 (1)"，结果就是你永远不知道哪个是哪个，而且磁盘上真实存在十几份内容完全一样的副本。
正确的做法是先算内容哈希，再决定：如果哈希相同，说明内容一模一样，只保留一份，其余的进"重复候选"列表让我确认；如果哈希不同，说明是不同版本，那就保留全部，但用一个能看到版本差异的命名规则区分，比如按时间和大小把改名的结果列出来。我在工具里配置的逻辑很简单——同目录内哈希相同就归并，哈希不同就按原名_日期_大小重命名。这样至少每份文件的差异是写在名字上的。
还有一类要特别小心：文件名里已经带v1/v2/final/最终版的，永远不要参与自动归并。这是我拿一次真实损失换来的教训，放在第 4 节细讲。
3.4 待定区：给"拿不准"留一块缓冲区
前面规则表里最后一行"不匹配任何条件就进待定区"，是整个流程里我最推荐的设计。清理过程中一定会有大量你怎么看都拿不准的文件，可能是某个项目的临时导出、可能是别人发来让你"有空看看"的资料、也可能只是名字被截断得一塌糊涂。传统整理法的处理是硬着头皮分类，结果就是分类标准崩掉；或者干脆跳过，结果就是这堆东西永远留在原地。
待定区的做法是：给这些文件一个单独的目录，并配上时间盒。我的规则是进待定区 30 天，30 天内没被打开过、也没被手动挪出来的，统一进入下一轮清理的候选名单。这样一来，你在第一轮根本不需要为这些文件纠结，只需要做一个"先放这儿"的动作，决策成本从 30 秒降到 1 秒。
注意：待定区目录本身要定期看体积。我这次清完，待定区里剩了 287 个文件、约 3.2 GB。一个月后再看，其中只有 6 个文件被我主动挪出去过。剩下 281 个的结局已经很清楚了。
第一轮清理完之后，文件总数从 4193 降到 3106，占用的 37.6 GB 降到 22.4 GB，但真正的收获不是省出来的 15 GB，而是目录深度从"全在一层"变成了"三层以内的清晰结构"，找东西从翻列表变成了进目录。
4. 去重：完全重复和近似重复是两个物种
去重是这类工具的招牌功能，也是最容易出事的功能。我在这上面栽过一次，所以现在把去重分成两条完全独立的路径：完全重复交给工具自动处理，近似重复只做聚簇提示，绝不自动动手。
4.1 三级漏斗：先粗筛，再精筛，最后才算全量哈希
对 4000 个文件直接算完整哈希是浪费。一个 4 GB 的素材包，全量读取一遍要几十秒，而绝大部分文件根本不需要走到这一步。我用的三级漏斗是这样的：
| 层级 | 方法 | 单文件耗时 | 干什么用 |
|---|---|---|---|
| 一级 | 按文件大小分组 | 近似 0 | 大小不同的文件不可能完全相同 |
| 二级 | 读头部 + 尾部各 1MB 算哈希 | 毫秒级 | 排除掉一批"大小相同但内容不同"的 |
| 三级 | 全量哈希 | 取决于文件大小 | 只对前两级都通过的文件做 |
一级过滤的效率很惊人：4000 个文件按大小分组后，真正存在"大小相同"情况的只有 600 多个。二级过滤之后剩 200 多个，这时候再做全量哈希，总耗时控制在几分钟以内。二级哈希的写法大概是这样：
import hashlib def partial_hash(path, chunk=1 << 20): h = hashlib.blake2b(digest_size=16) size = path.stat().st_size with open(path, "rb") as f: h.update(f.read(chunk)) if size > chunk * 2: f.seek(-chunk, 2) h.update(f.read(chunk)) h.update(str(size).encode()) return h.hexdigest()blake2b在这里比md5更合适，它速度更快、摘要长度可以自己指定，用来做"是不是同一个文件"的判断完全够用。有人在去重场景里坚持用sha256，那当然更稳，但对几万个文件的批量处理来说，多出来的时间成本换不来实际收益。
4.2 哈希耗时到底怎么估
很多人对哈希耗时没有概念，会觉得"算一下能有多慢"。真实数字取决于磁盘类型和文件大小：机械硬盘顺序读取大概 100 到 200 MB/s，SSD 在 500 MB/s 以上，较新的 NVMe 能到 2 到 3 GB/s。Rust 写的blake2b实现速度通常在 1 GB/s 量级，所以瓶颈几乎永远在磁盘 IO，不在 CPU。
按这个数字估算：如果你要全量哈希 100 GB 的数据，在机械硬盘上大约需要 500 到 1000 秒，在 SSD 上大约 200 秒。这也是为什么三级漏斗值得做——大部分文件在一级就被排除了，实际全量哈希的数据量往往只有总量的一到两成。
4.3 近似重复只做提示，不做处理
近似重复是另一个物种。同一张图片的不同分辨率版本、同一个视频的转码版本、同一份文档的不同修订稿，它们的哈希完全不同，但内容上高度相似。识别它们需要另一套算法：图片用感知哈希（pHash/dHash），音频用声纹指纹，文档用文本向量或 simhash。
这类结果我只用来生成"疑似重复"的聚簇列表，让人工看一眼再决定，绝不自动删除。原因很直接：近似重复的判定标准是模糊的，"相似度 92%"到底该不该算重复，取决于这文件对你意味着什么。工具没有这个上下文，只有你有。
4.4 我踩过的那个坑：把 v1 当成重复文件清掉了
2023 年我做一个品牌改版的活儿，中途客户突然说"能不能看看你最早那版方案"。我从下载文件夹里翻当时下载回来的设计稿，发现目录里有logo_v1.psd到logo_v9.psd一共九份。我用当时那个工具跑了一遍"智能清理"，它按哈希比对后判断：其中有三份是完全相同的中间文件，删了；另外六份是不同的版本，保留。听起来没问题。
问题在于，它同时把logo_v1.psd归到了"疑似重复"里，因为 v1 和 v3 的画面差异极小。而我在清理的时候没有仔细看那份提示清单，直接点了确认。等客户要看初版的时候，我才发现 v1 已经不在了——我手上最早的只剩 v3。
这件事之后我给自己加了两条硬规则：
- 文件名里出现
v1、v2、final、最终、副本、copy、rev这类版本标记的文件，一律不参与自动去重，只在列表里做灰色提示。 - 同一前缀的多版本文件，至少保留"最早"和"最新"各一份，中间的可以做提示，但不能默认勾选。
这两条规则写进工具之后，去重这件事我才敢放心交给它。顺便说一句，如果你的文件里版本意识很强（设计、文档、代码导出物都是这样），那在选型阶段就应该把"能不能配置排除规则"当成硬指标来考察，不能排除特定模式的工具，不管功能多花哨都别用。
5. 批量重命名：让文件名本身变成可检索的信息
清完一遍之后，我面对的是 3106 个文件。这时候最要紧的不是继续分类，而是让文件名变得有信息量。因为文件一旦多到一定程度，你实际上是靠搜索找东西的，而搜索的基础就是文件名。
5.1 命名模板：可检索优先于好看
设计命名模板的时候，我一度想搞一套漂亮的对齐格式，后来放弃了。模板的首要目标是可被搜索命中，不是好看。我的模板结构是这样的：
日期_类别_主题_版本.扩展名 20240512_报价_华东区年度_最终版.xlsx这份模板里有几个刻意的选择。日期放在最前面，因为按名称排序时它就等于按时间排序，这是最常用的排序方式；用下划线而不是空格，因为空格在命令行、脚本、部分工具里都要额外转义，处理起来烦；日期用YYYYMMDD这种八位纯数字，因为这种格式天然可按字符串比较，不会出现"5月12日"排在"12月3日"后面这种坑。
不同类别的模板我做了区分：
| 类别 | 模板 | 示例 |
|---|---|---|
| 文档 | 日期_主题_版本 | 20240512_华南区合同_终版.pdf |
| 素材 | 项目_类型_序号 | 品牌改版_图标_014.png |
| 截图 | 日期_设备_关键词 | 20240512_手机_报价页.png |
| 安装包 | 软件名_版本_平台 | 图像处理_3.4.1_win.exe |
| 影音 | 日期_主题_分辨率 | 20240401_产品演示_1080p.mp4 |
中文文件名在跨系统场景下确实有编码坑，比如某些压缩工具在不指定编码时会把中文名解成乱码。我的处理办法是：纯中文文件名只保留给确定在本机使用、不参与归档传输的文件；要打包发给别人的，统一用拼音或英文缩写。这个决定听起来麻烦，但比事后解压出一堆乱码省心得多。
5.2 时间戳该取哪一个：mtime、ctime、atime 的区别
批量重命名里最容易出问题的是时间。文件系统里有三个时间戳，名字很像，含义完全不同：
- mtime（修改时间）：文件内容最后一次被修改的时间。对于下载来的文件，它通常就是下载完成的时间，这是我最常用的那个。
- ctime（状态改变时间）：文件的元数据（权限、所有者、硬链接数）最后一次变化的时间。有些系统操作会刷新它，所以它不能代表"这个文件是什么时候产生的"。
- atime（访问时间）：文件最后一次被读取的时间。很多系统默认关闭或延迟更新它，所以它常常不可靠。
我要把日期写进文件名，选的是mtime。而且我在批量重命名之后，会主动把新文件的 mtime 设回原值——这一步非常关键，因为重命名操作在某些实现下会刷新时间戳，如果不管，你几千个文件的日期会在一瞬间全部变成今天，整个时间维度就废了。
import os old_mtime = os.stat(src).st_mtime os.rename(src, dst) os.utime(dst, (old_mtime, old_mtime))5.3 目录做粗分类，标签做横切
在目录结构上，我的经验是深度不要超过三层。原因很实际：第四层之后，你打开文件管理器就要开始滚动和点开文件夹，找东西的时间反而比搜索还长。三层是什么概念？大概是文档/2024/合同这个级别，再往下就没必要拆了。
但有些文件天生就跨类别，比如一张发票截图：它既属于"图片"，也属于"财务"，还属于某个具体项目。硬塞进一个目录必然失真。这类需求交给标签——目录负责粗分类，标签负责横切。工具里如果支持给文件打标签并把这些标签存进一个本地数据库（而不是写进文件的扩展属性，因为扩展属性在很多文件系统迁移时会丢），那实用性会高很多。
我目前的方案就是混合的：目录是三层结构，承载 80% 的查找场景；标签库承担剩下的 20%，比如"待报销"、"参考素材"、"客户A"。标签数据存在本地的 SQLite 里，和文件路径绑定，路径变了就靠哈希重新关联。
6. 索引与搜索：整理完之后如何保证它不再变乱
这是整个流程里最重要的一节。前面五节做的事，本质上是一次性清理；而一个三年没动过的文件夹，三个月后完全可能重新变成垃圾山。真正让整理不反弹的，是索引和巡检这两件事。
6.1 文件名索引和全文索引，成本差一个数量级
先说清楚两类索引的区别，因为很多人把这两件事混在一起谈。
文件名索引只读目录结构，不打开文件内容。在支持底层文件系统日志的操作系统上，这类工具可以做到"输一个字母，结果立刻出来"的程度，几百万文件的机器上查询也是毫秒级。它的建索引成本极低，首次全盘扫描可能几十秒，之后几乎零成本维护。
全文索引要打开每个文件抽取文本，然后做分词建倒排表。这个成本高得多：一份 PDF 抽文本几十毫秒到几百毫秒，一份几百页的大文档可能几秒。5000 个文档全量抽取，通常要几分钟到十几分钟，索引体积可能和源文件差不多大。
| 维度 | 文件名索引 | 全文索引 |
|---|---|---|
| 建索引耗时 | 秒级 | 分钟到十分钟级 |
| 索引占用 | 每文件几十字节 | 可达源文件的 50% 到 100% |
| 查询速度 | 毫秒 | 毫秒到几百毫秒 |
| 能搜到的内容 | 只有名字 | 正文内容 |
| 维护复杂度 | 低 | 需要处理增量更新 |
我的做法是两者都做，但分层：下载目录里给全部文件建文件名索引，保证随时能秒搜；只对"文档"这一类目录（pdf/docx/txt/md）建全文索引，因为这些才真正需要按内容找。影音和安装包不需要全文索引，给它们建索引纯属浪费磁盘。
用 SQLite FTS5 建全文索引的骨架大概是这样：
import sqlite3 con = sqlite3.connect("index.db") con.execute(""" CREATE VIRTUAL TABLE IF NOT EXISTS docs USING fts5(name, body, path UNINDEXED, tokenize='unicode61') """) def add_doc(name, body, path): con.execute("INSERT INTO docs(name, body, path) VALUES (?,?,?)", (name, body, path)) def search(kw): cur = con.execute( "SELECT name, path FROM docs WHERE docs MATCH ? ORDER BY rank LIMIT 30", (kw,) ) return cur.fetchall()unicode61这个分词器对中文的处理是"按字符切"，也就是说它没法做词级别的匹配，但做"包含这几个字"的模糊匹配是够用的。如果你要更强的中文分词，得引入专门的方案，那属于另一个复杂度级别了，我目前的场景用不上。
6.2 每周一次的低成本巡检，比半年一次的彻底整理有用得多
我现在的做法是每周五下午花十分钟做一次巡检，只看三个数字：
- 新增文件数：这一周下载目录新增了多少个文件。如果超过 100 个，说明我这一周下载得太随意了，下周要注意。
- 待定区体积：待定区目录现在多大。超过 2 GB 就触发一次快速清理，把 30 天前的按规则处理掉。
- 重复文件增长量：新增文件里有多少是重复的。这个数字能直接告诉你"是不是又在重复下载同一个东西"。
这三个数字加起来看，就是一份很直观的"收纳健康度"报告。十分钟的成本，换来的效果比半年后花五小时彻底重来要好得多，因为巡检处理的是增量，而彻底整理处理的是存量，前者的边际成本低太多。
6.3 最后说一个"入口闸门"的改动
真正让下载文件夹不再变乱的，其实是我改了一个设置：把浏览器的默认下载路径，从Downloads改成Downloads/2024-05（按月份或按周分桶）。
这个改动很小，但效果非常明显。原来所有文件都掉进同一个平面目录，几千个文件混在一起，每一次整理都要重新建立上下文。现在每个月一个子目录，单个目录里的文件量最多两三百个，天然就有了时间分界线——三个月前的目录我可以整体归档，不用逐个判断。
改完之后我又观察了一个月，新增文件 87 个，分布在 3 个按周分的子目录里，每个目录里都能一眼看完。到这个时候我才觉得，这个拖了三年的下载文件夹，是真的被解决掉了。
最后分享一个我自己在用的习惯：每次清理完之后，把那一轮的规则配置导出成一个文件存下来。因为下一次整理可能是半年后，你绝对不会记得上次为什么把.psd归到素材而不是图片。有了这份配置文件，你只需要导入再跑一遍，或者在此基础上微调两条规则，就能复用掉之前所有的思考成本。我从第一版规则到现在的第五版，前后改了十几条，全都是靠版本对比找出来的差异——这件事的收益，比我删掉的那 15 GB 大得多。
