1. 先说说我为什么要自己撸一个空文件夹扫描器去年年底我整理一块用了六七年的数据盘用资源管理器一层层点下去发现里面塞满了各种看起来有东西、点进去毛都没有的目录。有的嵌套五六层最里面是个空壳有的父目录里只躺着一个同样空的子目录还有一批是某同步客户端删除文件后留下的残缺结构。当时想找个现成工具一把扫出来试了几个要么只能扫一层要么扫完直接给你一键删除连个预览都不给看得我心里发毛。最后干脆自己写了个Windows 11 空文件夹扫描器前后迭代了四五个版本从最初 40 多分钟扫完一块 4TB 机械盘到后来 SSD 上三分钟出报告中间踩的坑比代码行数还多。这个工具说白了就干三件事递归遍历指定盘符或目录、按递归为空的规则判定、输出结构化报告可选隔离或删除。听起来简单但真做起来你会发现坑全藏在细节里——什么算空、遇到符号链接怎么办、权限拒绝的目录算不算空、长路径怎么处理、删之前怎么留后路。这几件事每一件都能让一个看起来能跑的脚本在真实盘上翻车。适合谁看手上有 Python 或 PowerShell 基础、想自己动手解决磁盘清洁问题的朋友对文件系统遍历、递归算法感兴趣的同学还有一类人——你已经用过别人的清理工具但不敢按下那个红色的删除按钮想搞清楚它到底在判断什么。下面我把整个项目从设计到实现的完整过程摊开讲代码可以直接抄判断逻辑你可以按自己的习惯改但删除环节请务必按我说的顺序来这部分我没有开玩笑。1.1 空文件夹到底占不占空间值不值得专门清先把一个常见误解掰扯清楚。很多人以为空文件夹占着磁盘空间其实在 NTFS 上一个空目录本身确实会消耗一点元数据MFT 里的一条记录通常几百字节到 1KB 量级但相对动辄几个 TB 的盘来说这点开销可以忽略。所以你不要指望清空文件夹能腾出多少 GB那是错觉。那为什么还要清因为它的成本不在空间在其他所有地方目录浏览成本一层层点进去发现是空的这个动作重复几百次人会烦。备份软件、增量同步工具扫描时也一样空目录会增加遍历节点数虽然单个开销小但几万个堆起来就是实打实的时间。同步与备份的判定逻辑大部分同步客户端是按目录存在与否来判断删除意图的。你在本地删了文件但残留了空目录某些客户端会认为目录还在只是内容没了于是把远端也清空但保留目录来回几次就形成一堆僵尸结构。版本控制与构建产物编译输出目录、临时缓存目录被清空后留下的空壳会让某些构建工具的增量判断失效也容易在提交时被误加入索引。心理负担这个理由听起来虚但很真实。一个结构混乱的盘你做任何整理决策都会变慢。所以我的定位很明确这是一个结构清洁工具不是空间回收工具。想省空间应该去查大文件、重复文件、休眠文件那是另一个赛道。把定位搞清楚了后面的设计取舍就顺了——既然不追求极致的空间收益那就必须在安全性上做到极致宁可少删不能错删。1.2 现成方案的三处短板和我最终的技术选型我先试了两条零成本路线各有各的问题。第一条是资源管理器手动翻。适合几十个目录几千个就算了人眼会漏而且你没法判断父目录为空是因为它自己空还是因为它下面全空。第二条是一行 PowerShell 命令。思路很直接找出所有目录然后对每个目录再枚举一次看里面有没有东西Get-ChildItem -LiteralPath D:\ -Directory -Recurse -Force -ErrorAction SilentlyContinue | Where-Object { -not (Get-ChildItem -LiteralPath $_.FullName -Force -ErrorAction SilentlyContinue) } | Select-Object FullName, LastWriteTime这条命令能跑但有两个硬伤。第一它只判直接为空不判递归为空。也就是说 A 目录里只有一个空的 B 目录A 本身不会被列出来你得反复跑几轮才能收敛。第二性能极差目录数量是 N每个目录再枚举一次等于把整个文件系统遍历了两遍而且Get-ChildItem在深层嵌套下还有额外的对象开销。我实测一块 4TB 机械盘跑这条命令二十分钟还没出结果CtrlC 了。第三条是现成的第三方清理工具。功能是强但普遍存在两个让我不放心的地方一是判定规则不透明你不知道它把哪些目录算成空二是一键删除缺少有效的中间缓冲有些工具确实有回收站支持但回收站在跨卷、大批量、超长路径场景下并不可靠。所以最后我选了自己写Python 做主力PowerShell 做快速验证。理由如下选型优势我的顾虑最终定位Python 标准库跨版本稳定、os.scandir性能好、调试方便、写报告容易首次运行需要装解释器主力工具完整功能PowerShell 脚本系统自带、无需安装、适合临时排查大目录下慢、长路径支持一般现场快速验证C# 小工具性能和长路径支持最好、可打包成单文件开发成本高、编译环境麻烦数据量极大时的备选现成第三方工具开箱即用规则不透明、删除不可控不用于删除只用于交叉验证结果这个表是我在真实项目里定下来的分工用了大半年没变过。核心逻辑一句话扫描用 Python验证用 PowerShell删除永远走我自己的三级流程。2. 核心判定逻辑到底什么才算空这部分是整个项目的地基地基歪了后面全歪。我见过不少人写的第一版是这样的枚举目录看len(os.listdir(path)) 0是就加进结果。这个写法有三个致命问题我一个个说。2.1 三种空的定义差异以及我为什么选第三种第一种直接为空。目录里一个条目都没有。这个最好判但漏得多。第二种递归为空。目录里没有文件且它下面的所有子目录也都是递归为空的。这是我最终采用的规则也是绝大多数清理工具的实际语义。第三种逻辑为空。忽略隐藏文件、忽略系统文件比如desktop.ini、.DS_Store这类、忽略指定后缀后的空。这个规则听起来很美但我坚决不用。原因很简单一旦引入忽略判定结果就依赖于一份看不见的名单你今天忽略desktop.ini明天就可能有人加上忽略所有小于 1KB 的文件——这就从清理空目录滑向了清理我认为不重要的东西风险等级完全不同。举个真实例子。某次我用别人的工具清一个素材盘结果某个目录里本来放着一批占位用的配置文件被判定为空后整个目录连同配置一起没了那批配置是某软件首次启动的模板重装才能恢复。从那以后我的规则就钉死了只有物理上递归为空才算空任何忽略都是红线。判定递归为空的数学表达其实很简单。设目录 D 的条目集合为 E(D)那么Empty(D) 对所有 e ∈ E(D)e 是目录 且 Empty(e)也就是说只要有任意一个文件或者任意一个非空目录D 就不算空。这个定义是自底向上的所以遍历顺序必须是后序先处理子再处理父这就是下一节要讲的。2.2 后序遍历是这个算法的骨架不能换为什么强调后序因为父目录的判定结果依赖所有子目录的判定结果。你要是按前序先父后子来走到父目录时子目录还没算只能先记个待定回头再补一遍等于多跑一轮。我用os.walk的topdownFalse参数来实现这是最省事的写法import os def scan_empty_dirs(root, on_errorNone, should_skipNone): 自底向上扫描递归为空的目录返回集合 empty_set set() if should_skip is None: should_skip lambda p: False for dirpath, dirnames, filenames in os.walk( root, topdownFalse, onerroron_error, followlinksFalse ): if should_skip(dirpath): continue # 只要有任何文件目录就非空 if filenames: continue # 子目录里只要有一个不是空的本目录就非空 all_children_empty True for d in dirnames: child os.path.join(dirpath, d) if child not in empty_set: all_children_empty False break if all_children_empty: empty_set.add(dirpath) return empty_set这段代码不到 30 行但有三处设计值得单独拎出来讲。第一处filenames的判断放在最前面。这是个短路优化绝大多数非空目录会在这一步被干掉省掉了后续的子目录比对。实测在文件密集的盘上这一句能让整体耗时降低三成左右因为省下的是纯 Python 层的字符串拼接和集合查询。第二处空集合用set而不是list。你可能会想几万个目录集合查询和列表查询能差多少差很多。列表查询是 O(n)整个扫描过程里每个子目录都要查一次总复杂度会退化成 O(n²)。我用 3 万个空目录实测过一次set版本 0.4 秒list版本 20 秒以上差距超过 40 倍。这个坑很隐蔽因为小盘上你根本测不出来。第三处followlinksFalse必须显式写。参数默认值是False但很多示例代码没写读者照抄之后遇到符号链接就进入死循环。显式写出来是为了让后来看代码的人知道这里有意为之而不是忘了。还有一个容易被忽略的细节os.walk的onerror回调。默认情况下遇到没权限的目录它会静默跳过这在扫描时是对的但在做报告时是危险的——你会以为自己扫完了全盘实际上漏了一大片。我的处理方式是把错误收集起来扫完单独打一份未能访问清单让使用者知道结果覆盖了多大范围def handle_error(err): denied.append({ path: getattr(err, filename, ?), reason: err.strerror or str(err), }) denied [] empty scan_empty_dirs(D:\\, on_errorhandle_error) print(f空目录 {len(empty)} 个未访问 {len(denied)} 个)2.3 符号链接与重解析点递归里的死循环陷阱这是 Windows 上最容易被低估的一个问题我在真实盘上栽过一次。场景是这样的某个目录下有一个指向它自己祖先目录的软链接。遍历程序老老实实跟进去又走到同一个目录再跟进去……直到路径长度爆炸或者栈溢出。更阴险的是目录联接Junction它在资源管理器里显示为一个带小箭头的文件夹图标和普通目录几乎一样但os.path.islink()在旧版本 Python 上对它的返回值是False——也就是说你以为设了followlinksFalse就安全了实际上它压根没被当成链接。正确做法是检查文件属性里的重解析点标志import os import stat def is_reparse_point(entry) - bool: 判断 scandir 条目是否为重解析点符号链接、Junction、挂载点 try: st entry.stat(follow_symlinksFalse) except OSError: return True # 拿不到属性就当作危险项跳过 attrs getattr(st, st_file_attributes, 0) return bool(attrs stat.FILE_ATTRIBUTE_REPARSE_POINT)stat.FILE_ATTRIBUTE_REPARSE_POINT这个常量只在 Windows 上存在用getattr兜底是为了让同一份代码在别的系统上不至于直接抛异常。这里有个小技巧拿不到属性时返回True当作危险项跳过而不是False。这是安全设计里的失败关闭原则——不确定的东西一律不碰。把这些链接排除之后判定逻辑还要改一处一个只包含重解析点的目录算不算空我的答案是不算。因为它虽然递归为空但你把它删掉时那个链接本身也会消失而使用者可能还需要它。所以在扫描阶段我会给这类目录单独打一个标记has_reparse报告里归到疑似空但含链接需人工确认那一类跟真正的空目录分开展示。这个分类后来救了我好几次下面第 6 节会讲一个具体案例。3. 动手实现从最小可用版本到能日常用前面两节讲的是想清楚这一节讲写出来。我给的建议是不要一上来就写完整版先写一个 20 行能出结果的脚本拿一个小目录试跑通了再往上加功能。一上来就搞进度条、多线程、报告导出你会在一堆自己写的代码里迷路。3.1 环境准备与项目骨架环境很简单Python 3.8 以上只用标准库一个依赖都不用装。我特意没用第三方库理由是这类工具的受众常常是在别人的机器上临时用装依赖这一步就能劝退一半人。文件夹结构我习惯这样摆empty-dir-scanner/ ├── scanner.py # 核心扫描逻辑可被 import ├── report.py # 报告生成CSV 文本 ├── quarantine.py # 隔离区管理 ├── rules.json # 白名单与排除规则 └── logs/ # 扫描日志与错误清单为什么把扫描和删除分成两个文件因为我想强制自己遵守一个纪律扫描程序不应该有删除能力。scanner.py里出现os.rmdir或者shutil.rmtree就是违规这个约束在代码审查时一眼可见。真正删除的动作放在quarantine.py而它只接受一份已经审阅过的清单文件作为输入。这个物理隔离看起来多余但它挡住了我至少两次手滑——写循环的时候不小心把删除写进了扫描分支因为文件分层IDE 会直接报未导入。配置文件我用的 JSON虽然不如 YAML 好看但它不需要额外解析器。内容大致是{ exclude_patterns: [.git, node_modules, __pycache__], protect_paths: [D:\\工作区, D:\\归档], min_age_days: 7, dry_run: true }min_age_days这个字段值得说一下。它的作用是只报告修改时间早于 N 天前的空目录。为什么加这个因为很多程序在运行时会临时创建目录再删掉你正好在中间那个瞬间扫过去就会误判。给一个时间缓冲能避免大部分这类动了不该动的东西的事故。默认 7 天是我拍的经验值你可以按自己的使用强度调。3.2 核心遍历函数逐行拆解上一节的os.walk版本是骨架真要上生产还得补三样东西排除规则、重解析点标记、以及每个空目录的元信息采集创建时间、最后修改时间、层级深度、父目录。我把它重写成了显式栈版本因为os.walk拿不到scandir条目的缓存元信息还得再stat一次白白多一轮系统调用import os import time from datetime import datetime def scan(root, config, progressNone): 迭代式后序遍历返回 (empty_dirs, skipped, errors) empty_dirs: [{path, depth, mtime, has_reparse}] result {} # path - bool(是否递归为空) meta {} # path - dict empty_dirs [] errors [] visited set() stack [(root, 0, False)] # (路径, 深度, 是否已回退) done 0 while stack: path, depth, is_post stack.pop() if is_post: # 回退阶段判定当前目录 m meta.get(path) if m is None: continue if m[has_file]: result[path] False elif m[has_reparse]: result[path] None # 需人工确认 empty_dirs.append({**m, status: suspect}) elif all(result.get(c) is True for c in m[children]): result[path] True empty_dirs.append({**m, status: empty}) else: result[path] False done 1 if progress and done % 500 0: progress(done, len(stack)) continue # 进入阶段 real os.path.realpath(path) if real in visited: continue visited.add(real) try: entries list(os.scandir(path)) except OSError as e: errors.append({path: path, reason: e.strerror or str(e)}) result[path] False continue info { path: path, depth: depth, has_file: False, has_reparse: False, children: [], mtime: datetime.fromtimestamp( os.stat(path, follow_symlinksFalse).st_mtime), } children [] for e in entries: if is_reparse_point(e): info[has_reparse] True continue if e.is_dir(follow_symlinksFalse): children.append(e.path) else: info[has_file] True info[children] children meta[path] info # 先压回退标记再压子目录保证子目录先出栈 stack.append((path, depth, True)) for c in children: stack.append((c, depth 1, False)) return empty_dirs, done, errors这段代码里最需要理解的是栈的压入顺序。栈是后进先出所以要让回退标记最后被弹出它必须最先被压入。如果你写反了程序不会报错但你会得到一个全空的结果集——所有目录在子目录处理完之前就被判定了。我第一次写这段的时候调了将近两个小时加了一堆 print 才看出来是顺序问题。记住这个口诀回退标记先入栈子目录后入栈弹栈时子目录先出标记最后出。另外visited集合用的是os.path.realpath的结果。这一步防的是硬链接和挂载点造成的重复遍历虽然 Windows 上这种情况比 Linux 少但外接盘、虚拟盘符、网络映射都可能触发。用 realpath 有一点性能开销每次都要解析路径实测在 100 万文件规模下大概多花 5% 的时间我认为这笔保险费值得交。3.3 进度反馈、日志与断点续扫扫大盘的时候没进度反馈是很折磨人的你不知道它是卡住了还是在干活。我的进度显示很简单每处理 500 个目录刷一行已处理 12500 个目录 | 栈内待处理 3400 | 已发现空目录 812 | 用时 00:02:41关键指标选的是栈内待处理而不是剩余百分比。因为磁盘遍历的剩余量在扫之前根本无法预估硬编一个百分比只会得到一个先快后停、最后突然跳到 100% 的假进度条看了更焦虑。栈深度是个真实增长的数字看它能判断程序还在推进。日志我建议一定要写文件而且要分两份一份是空目录清单一份是错误和应用清单。前者是结果后者是免责依据。我在报告头里固定写这么几行扫描根路径D:\ 开始时间2025-01-11 21:03:12 结束时间2025-01-11 21:06:48 目录总数486221 发现空目录12483其中含链接需确认37 无法访问214 跳过白名单192 工具版本0.9.3 参数min_age_days7这份头部信息比结果本身还重要。半年后你回头看某个目录为什么被删了能靠这些参数复现判断过程。断点续扫我这个项目最后没做原因是成本收益不划算。一次全盘扫描也就几分钟真中断了重跑就行。但如果你要扫的是网络位置或者超大冷存储可以加一个简单的检查点每处理 1 万个目录把visited和result序列化到磁盘。我用的是pickle虽然不那么优雅但它是标准库而且这类临时状态文件不怕格式不兼容。3.4 长路径和权限Windows 上绕不过去的两道坎长路径问题。传统上路径总长度限制在 260 个字符超过之后很多操作会直接失败。在深层嵌套的项目目录里比如某些包管理器的依赖树这个限制很容易撞上。现代系统可以通过开启长路径支持来解除具体是注册表里那个LongPathsEnabled开关。但我不建议工具去改系统设置而是在自己的代码里兼容两种情形def to_extended_path(p: str) - str: 给路径加 \\?\ 前缀以绕过长度限制 if p.startswith(\\\\?\\): return p if p.startswith(\\\\): return \\\\?\\UNC\\ p[2:] # 网络路径的特殊写法 return \\\\?\\ p注意网络路径\\server\share要转成\\?\UNC\server\share直接加前缀会失效。这个细节很多示例代码都写错了。实际使用中我的策略是长度超过 240 就自动加前缀短路径保持原样。因为加前缀之后有些 API 的行为会变比如不再自动做路径规范化能不用就不用。权限问题。系统目录、其他用户的配置目录、某些带 ACL 保护的文件夹都会返回拒绝访问。这里的态度要非常明确拒绝访问 ≠ 空。我把它归到未知类报告里单独列出来绝对不参与删除。上面代码里的errors列表就是干这个的。有个反面案例某工具为了扫得干净遇到拒绝访问的目录直接跳过并当成空处理结果把一批受保护目录列出去了使用者一键清理后系统功能异常。这种设计思路我完全不能接受。4. 删除环节才是真正的危险区写到这里扫描部分已经能出结果了。接下来是真正需要谨慎的部分。我的原则只有一条扫描可以激进删除必须保守。4.1 三级策略只报告、进隔离区、真删我把删除分成三个等级默认永远停在第一级级别动作可逆性触发方式L1 报告只生成清单不动文件完全可逆默认行为L2 隔离移动到隔离区目录保留原路径记录可一键回滚显式加--quarantineL3 删除调用os.rmdir删除空目录不可逆仅空目录显式加--purge且二次确认为什么用os.rmdir而不是shutil.rmtree因为os.rmdir只能删空目录目录里只要有一个文件它就报错退出。这是一个天然的安全锁——即使你的判定逻辑出了 bug把非空目录列进了清单rmdir也会拒绝执行而不是把里面的东西一起带走。shutil.rmtree是递归删除用在空目录工具里属于杀鸡用牛刀而且一旦判断失误后果不可收拾。这个选择我从来没犹豫过。还有一个细节删除顺序必须从深到浅。因为删掉最内层之后父目录可能变成空的这时候可以顺势一起删掉这就是所谓的级联清理。上面的os.walk(topdownFalse)天然给出深度优先的顺序直接按列表顺序处理即可。但要注意如果你用的是自己的显式栈版本返回的empty_dirs是按回退顺序排列的也就是深在前、浅在后正好可以直接遍历。4.2 隔离区设计给手滑留一条后路隔离区说白了就是把空目录搬到另一个地方存着。但空目录有个特殊性——你没法直接移动一个空目录再指望它保持结构因为你移动它的时候它在原位置就消失了而原位置的父目录可能因此变空记录就乱了。我的做法是不移动目录本身而是记录一份待恢复清单然后删除。清单里存每个目录的完整路径、创建时间、修改时间、层级深度。回滚的时候按原样重建目录和属性import json, os from datetime import datetime def purge_with_manifest(empty_dirs, manifest_path): deleted [] for item in sorted(empty_dirs, keylambda x: -x[depth]): p item[path] try: os.rmdir(p) # 只删空目录非空会抛异常 deleted.append({ path: p, mtime: item[mtime].isoformat(), }) except OSError as e: print(f[跳过] {p} - {e.strerror}) with open(manifest_path, w, encodingutf-8) as f: json.dump({ created_at: datetime.now().isoformat(), root: empty_dirs[0][path] if empty_dirs else , items: deleted, }, f, ensure_asciiFalse, indent1) print(f已删除 {len(deleted)} 个清单写入 {manifest_path})对应的回滚脚本就是把清单读出来按层级从浅到深依次os.makedirs再用os.utime恢复时间戳def restore(manifest_path): data json.load(open(manifest_path, encodingutf-8)) items sorted(data[items], keylambda x: x[path].count(os.sep)) for it in items: os.makedirs(it[path], exist_okTrue) ts datetime.fromisoformat(it[mtime]).timestamp() os.utime(it[path], (ts, ts)) print(f已恢复 {len(items)} 个目录)这套机制的价值不在于真的能 100% 还原空目录里本来就没东西还原的是结构和时间戳而在于它让删除这个动作变成了可审计的。你知道删了什么、什么时候删的、原来长什么样。有一次我误删了某个项目的目录骨架就是靠这份清单十分钟内全部重建连修改时间都对上了。4.3 白名单与护栏让工具知道哪些地方不能碰护栏我设了四层任何一层命中就跳过第一层路径前缀保护。配置里写的protect_paths做前缀匹配。注意匹配时要处理路径分隔符D:\工作区不该匹配到D:\工作区备份所以要补一个分隔符再比。这个 bug 我在第一版就犯了工作区备份被当成工作区的子路径保护起来了反倒漏掉了一大片。第二层目录名排除。像版本控制目录、依赖目录、缓存目录这类不管空不空都不动。判断方法是取路径的最后一段做精确匹配不要用子串包含——用包含的话my_git_notes会被.git规则误伤。第三层时间门槛。前面说的min_age_days修改时间太新的跳过。这条规则挡掉的是程序正在使用中的临时目录。第四层数量与比例熔断。这个是我加的最有用的一条如果一次扫描发现的空目录超过总目录数的 30%或者绝对数量超过 5 万程序停止并只输出报告拒绝进入删除流程。因为这种量级的异常通常意味着判定逻辑出问题了比如权限大面积失败导致大量目录被误判为空这时候最该做的是人工复核而不是继续执行。5. 性能调优实录从 40 分钟到 3 分钟第一版跑 4TB 机械盘花了 40 多分钟当时我以为这就是磁盘的极限了后来做了几件事同样的盘降到 6 分钟出头换到固态上只要 3 分钟。这部分经验可能比代码本身更有价值。5.1 瓶颈定位先测再改别凭感觉我先做了一件事分段计时。在扫描循环里插桩统计每个阶段的累计耗时阶段首版耗时占比说明os.scandir枚举41%系统调用受磁盘和目录碎片影响os.stat取属性27%每个条目一次调用os.path.join拼路径18%纯 Python 字符串操作集合查询与判定9%结构问题时会暴涨日志与进度输出5%输出太频繁也会拖慢这个表一出来优化方向就很明确了scandir的部分动不了那是磁盘的物理限制但stat和join完全可以省。5.2 具体优化手段与实测收益优化一用scandir的缓存替代单独stat。os.scandir返回的DirEntry对象在 Windows 上会缓存一部分属性调用entry.is_dir()、entry.stat()时不一定触发新的系统调用。我原来的代码是先scandir拿名字再os.path.join拼完整路径再os.stat。改成直接用entry.is_dir(follow_symlinksFalse)之后stat调用量下降了大约七成。这一项单独贡献了将近 30% 的整体提速。优化二延迟拼接完整路径。只有确认需要递归进去的子目录才拼完整路径。文件条目根本不需要拼因为只要发现一个文件当前目录就直接判定为非空。原代码对每个条目都拼路径纯属浪费。优化三日志改成批量刷写。原来每发现一个空目录就print一次输出到控制台的重定向开销在小规模下看不出来十万级的时候就非常明显了。改成累积到 500 条刷一次或者直接写文件缓冲。优化四多线程枚举。这一项要谨慎。文件系统遍历是 IO 密集型理论上多线程有收益但机械盘上基本没收益甚至更慢因为磁头来回寻道。我实测过机械盘 4 线程比单线程慢 12%固态盘 4 线程比单线程快 45%。所以我的实现里加了一个开关默认关闭检测到目标盘是固态再打开。检测方法很土但有效看盘符对应的设备类型拿不到就保守按机械盘处理。优化五跳过明显无关的目录。系统还原目录、休眠文件目录、某些索引目录这些地方你既不该扫也不该删。在进入阶段用前缀快速判断能省掉大量无意义遍历。我在一块系统盘上试过跳过几个大目录之后扫描节点数直接少了一半。把这五项叠加最终的效果是4TB 机械盘 6 分 20 秒1TB 固态 2 分 50 秒扫描节点数 120 万左右。这个成绩我认为够用了再往下优化就得碰底层 API 了性价比不高。6. 常见问题速查与踩过的坑这一节是我最想写的部分。前面讲的都是应该怎么设计这里讲的是实际会怎么坏。6.1 典型问题与处理对照表现象根因处理方式扫描结果里出现明显非空的目录权限失败被当成空处理检查错误清单确认拒绝访问的目录被归为未知程序卡死不动CPU 占用不高遇上了循环链接检查重解析点判定是否生效删除时报目录不是空的判定后目录被程序写入新文件属正常现象跳过即可不要强删扫出来的数量明显偏少路径过长导致枚举失败加\\?\前缀或检查系统长路径开关报告里的中文路径显示乱码文件编码问题统一用 UTF-8 写入读取端也指定编码同一个目录在结果里出现两次通过不同路径访问到同一位置用realpath去重扫描极慢磁盘灯常亮机械盘上开了多线程关掉并发单线程顺序读级联删除删多了父目录本来就不该删加白名单前缀删除后立即停止向上传递时间门槛过滤后仍误删目录被程序 touch 过同时参考创建时间和修改时间隔离清单无法还原清单里存的是相对路径一律存绝对路径表里最后一条我需要多说一句。第一版我为了可移植清单里存的是相对于扫描根的路径。结果有次换了扫描根还原脚本把一百多个目录重建到了错误的位置还得一个个手动清理。这类清单永远存绝对路径可移植性在这个场景里毫无价值。6.2 几条用血换来的经验第一条永远先跑 dry-run而且要看前 50 条。我的工具默认就是 dry-run要真删必须显式加参数。但光这样还不够——很多人扫完直接拖到清单底部按下执行前面的内容根本没看。我现在的习惯是强制看前 50 条和最后 50 条中间随机抽 20 条。为什么因为误判往往集中在特定区域要么是某类特殊结构的目录出现在前部或后部要么是某个特定盘的路径随机抽样能碰到。有次随机抽查就发现一批空目录其实是某个工程的脚手架虽然当时确实是空的但那是构建前生成的删了下一次构建会报奇怪的错。第二条含重解析点的目录单独归类不要混进空目录。前面提过一次这里展开说。某次扫描出来一批空目录其中 37 个带链接标记。我当时没细看差点一起清掉。后来发现其中一个是某软件运行必需的目录占位它靠这个位置存在与否判断运行环境另几个是人为创建的快捷方式目录用来快速跳转到其他盘。这些东西删了不影响数据安全但会让人莫名其妙地某个功能突然不好用了。所以现在这类目录永远走status: suspect分支报告里单独一节标题就叫需人工确认。第三条不要相信回收站。很多人觉得删到回收站就安全了。批量删除几百上千个目录时回收站的操作会很慢而且它本身有自己的容量限制超了之后旧内容会被静默清掉。更要命的是空目录进回收站的行为在不同系统版本上不一致有些版本会直接跳过空目录不进回收站——你以为进了回收站其实已经删了。所以我的方案是完全绕开回收站走自己的隔离清单。第四条给每次运行一个独立的工作目录。日志、清单、错误报告全放到logs/20250111-2103/这种按时间戳命名的目录里。早期我图省事所有运行都往同一个文件里覆盖写结果出了问题时想看上一次的记录早就被覆盖了。这个成本极低收益极高。第五条定期用另一个工具交叉验证结果。我会用 PowerShell 那行命令抽查几个目录看看两边结论是否一致。如果差异超过 5%说明其中一方有问题这时候就该停下来查判定逻辑而不是继续往下走。最后分享一个我自己的使用节奏。我不做定时全盘扫描而是在三种时机手动触发一是重装或大版本升级某软件之后二是做完整盘备份之前避免把垃圾一起备份三是感觉某个盘点起来很卡的时候。每次都是 dry-run、看报告、确认、隔离、观察一周、没问题再清空清单。这个流程听起来啰嗦但一年下来清清淡淡地过了十几次一次事故都没有。慢一点稳一点工具的边界就守住了。
1. 先说说我为什么要自己撸一个空文件夹扫描器去年年底我整理一块用了六七年的数据盘用资源管理器一层层点下去发现里面塞满了各种看起来有东西、点进去毛都没有的目录。有的嵌套五六层最里面是个空壳有的父目录里只躺着一个同样空的子目录还有一批是某同步客户端删除文件后留下的残缺结构。当时想找个现成工具一把扫出来试了几个要么只能扫一层要么扫完直接给你一键删除连个预览都不给看得我心里发毛。最后干脆自己写了个Windows 11 空文件夹扫描器前后迭代了四五个版本从最初 40 多分钟扫完一块 4TB 机械盘到后来 SSD 上三分钟出报告中间踩的坑比代码行数还多。这个工具说白了就干三件事递归遍历指定盘符或目录、按递归为空的规则判定、输出结构化报告可选隔离或删除。听起来简单但真做起来你会发现坑全藏在细节里——什么算空、遇到符号链接怎么办、权限拒绝的目录算不算空、长路径怎么处理、删之前怎么留后路。这几件事每一件都能让一个看起来能跑的脚本在真实盘上翻车。适合谁看手上有 Python 或 PowerShell 基础、想自己动手解决磁盘清洁问题的朋友对文件系统遍历、递归算法感兴趣的同学还有一类人——你已经用过别人的清理工具但不敢按下那个红色的删除按钮想搞清楚它到底在判断什么。下面我把整个项目从设计到实现的完整过程摊开讲代码可以直接抄判断逻辑你可以按自己的习惯改但删除环节请务必按我说的顺序来这部分我没有开玩笑。1.1 空文件夹到底占不占空间值不值得专门清先把一个常见误解掰扯清楚。很多人以为空文件夹占着磁盘空间其实在 NTFS 上一个空目录本身确实会消耗一点元数据MFT 里的一条记录通常几百字节到 1KB 量级但相对动辄几个 TB 的盘来说这点开销可以忽略。所以你不要指望清空文件夹能腾出多少 GB那是错觉。那为什么还要清因为它的成本不在空间在其他所有地方目录浏览成本一层层点进去发现是空的这个动作重复几百次人会烦。备份软件、增量同步工具扫描时也一样空目录会增加遍历节点数虽然单个开销小但几万个堆起来就是实打实的时间。同步与备份的判定逻辑大部分同步客户端是按目录存在与否来判断删除意图的。你在本地删了文件但残留了空目录某些客户端会认为目录还在只是内容没了于是把远端也清空但保留目录来回几次就形成一堆僵尸结构。版本控制与构建产物编译输出目录、临时缓存目录被清空后留下的空壳会让某些构建工具的增量判断失效也容易在提交时被误加入索引。心理负担这个理由听起来虚但很真实。一个结构混乱的盘你做任何整理决策都会变慢。所以我的定位很明确这是一个结构清洁工具不是空间回收工具。想省空间应该去查大文件、重复文件、休眠文件那是另一个赛道。把定位搞清楚了后面的设计取舍就顺了——既然不追求极致的空间收益那就必须在安全性上做到极致宁可少删不能错删。1.2 现成方案的三处短板和我最终的技术选型我先试了两条零成本路线各有各的问题。第一条是资源管理器手动翻。适合几十个目录几千个就算了人眼会漏而且你没法判断父目录为空是因为它自己空还是因为它下面全空。第二条是一行 PowerShell 命令。思路很直接找出所有目录然后对每个目录再枚举一次看里面有没有东西Get-ChildItem -LiteralPath D:\ -Directory -Recurse -Force -ErrorAction SilentlyContinue | Where-Object { -not (Get-ChildItem -LiteralPath $_.FullName -Force -ErrorAction SilentlyContinue) } | Select-Object FullName, LastWriteTime这条命令能跑但有两个硬伤。第一它只判直接为空不判递归为空。也就是说 A 目录里只有一个空的 B 目录A 本身不会被列出来你得反复跑几轮才能收敛。第二性能极差目录数量是 N每个目录再枚举一次等于把整个文件系统遍历了两遍而且Get-ChildItem在深层嵌套下还有额外的对象开销。我实测一块 4TB 机械盘跑这条命令二十分钟还没出结果CtrlC 了。第三条是现成的第三方清理工具。功能是强但普遍存在两个让我不放心的地方一是判定规则不透明你不知道它把哪些目录算成空二是一键删除缺少有效的中间缓冲有些工具确实有回收站支持但回收站在跨卷、大批量、超长路径场景下并不可靠。所以最后我选了自己写Python 做主力PowerShell 做快速验证。理由如下选型优势我的顾虑最终定位Python 标准库跨版本稳定、os.scandir性能好、调试方便、写报告容易首次运行需要装解释器主力工具完整功能PowerShell 脚本系统自带、无需安装、适合临时排查大目录下慢、长路径支持一般现场快速验证C# 小工具性能和长路径支持最好、可打包成单文件开发成本高、编译环境麻烦数据量极大时的备选现成第三方工具开箱即用规则不透明、删除不可控不用于删除只用于交叉验证结果这个表是我在真实项目里定下来的分工用了大半年没变过。核心逻辑一句话扫描用 Python验证用 PowerShell删除永远走我自己的三级流程。2. 核心判定逻辑到底什么才算空这部分是整个项目的地基地基歪了后面全歪。我见过不少人写的第一版是这样的枚举目录看len(os.listdir(path)) 0是就加进结果。这个写法有三个致命问题我一个个说。2.1 三种空的定义差异以及我为什么选第三种第一种直接为空。目录里一个条目都没有。这个最好判但漏得多。第二种递归为空。目录里没有文件且它下面的所有子目录也都是递归为空的。这是我最终采用的规则也是绝大多数清理工具的实际语义。第三种逻辑为空。忽略隐藏文件、忽略系统文件比如desktop.ini、.DS_Store这类、忽略指定后缀后的空。这个规则听起来很美但我坚决不用。原因很简单一旦引入忽略判定结果就依赖于一份看不见的名单你今天忽略desktop.ini明天就可能有人加上忽略所有小于 1KB 的文件——这就从清理空目录滑向了清理我认为不重要的东西风险等级完全不同。举个真实例子。某次我用别人的工具清一个素材盘结果某个目录里本来放着一批占位用的配置文件被判定为空后整个目录连同配置一起没了那批配置是某软件首次启动的模板重装才能恢复。从那以后我的规则就钉死了只有物理上递归为空才算空任何忽略都是红线。判定递归为空的数学表达其实很简单。设目录 D 的条目集合为 E(D)那么Empty(D) 对所有 e ∈ E(D)e 是目录 且 Empty(e)也就是说只要有任意一个文件或者任意一个非空目录D 就不算空。这个定义是自底向上的所以遍历顺序必须是后序先处理子再处理父这就是下一节要讲的。2.2 后序遍历是这个算法的骨架不能换为什么强调后序因为父目录的判定结果依赖所有子目录的判定结果。你要是按前序先父后子来走到父目录时子目录还没算只能先记个待定回头再补一遍等于多跑一轮。我用os.walk的topdownFalse参数来实现这是最省事的写法import os def scan_empty_dirs(root, on_errorNone, should_skipNone): 自底向上扫描递归为空的目录返回集合 empty_set set() if should_skip is None: should_skip lambda p: False for dirpath, dirnames, filenames in os.walk( root, topdownFalse, onerroron_error, followlinksFalse ): if should_skip(dirpath): continue # 只要有任何文件目录就非空 if filenames: continue # 子目录里只要有一个不是空的本目录就非空 all_children_empty True for d in dirnames: child os.path.join(dirpath, d) if child not in empty_set: all_children_empty False break if all_children_empty: empty_set.add(dirpath) return empty_set这段代码不到 30 行但有三处设计值得单独拎出来讲。第一处filenames的判断放在最前面。这是个短路优化绝大多数非空目录会在这一步被干掉省掉了后续的子目录比对。实测在文件密集的盘上这一句能让整体耗时降低三成左右因为省下的是纯 Python 层的字符串拼接和集合查询。第二处空集合用set而不是list。你可能会想几万个目录集合查询和列表查询能差多少差很多。列表查询是 O(n)整个扫描过程里每个子目录都要查一次总复杂度会退化成 O(n²)。我用 3 万个空目录实测过一次set版本 0.4 秒list版本 20 秒以上差距超过 40 倍。这个坑很隐蔽因为小盘上你根本测不出来。第三处followlinksFalse必须显式写。参数默认值是False但很多示例代码没写读者照抄之后遇到符号链接就进入死循环。显式写出来是为了让后来看代码的人知道这里有意为之而不是忘了。还有一个容易被忽略的细节os.walk的onerror回调。默认情况下遇到没权限的目录它会静默跳过这在扫描时是对的但在做报告时是危险的——你会以为自己扫完了全盘实际上漏了一大片。我的处理方式是把错误收集起来扫完单独打一份未能访问清单让使用者知道结果覆盖了多大范围def handle_error(err): denied.append({ path: getattr(err, filename, ?), reason: err.strerror or str(err), }) denied [] empty scan_empty_dirs(D:\\, on_errorhandle_error) print(f空目录 {len(empty)} 个未访问 {len(denied)} 个)2.3 符号链接与重解析点递归里的死循环陷阱这是 Windows 上最容易被低估的一个问题我在真实盘上栽过一次。场景是这样的某个目录下有一个指向它自己祖先目录的软链接。遍历程序老老实实跟进去又走到同一个目录再跟进去……直到路径长度爆炸或者栈溢出。更阴险的是目录联接Junction它在资源管理器里显示为一个带小箭头的文件夹图标和普通目录几乎一样但os.path.islink()在旧版本 Python 上对它的返回值是False——也就是说你以为设了followlinksFalse就安全了实际上它压根没被当成链接。正确做法是检查文件属性里的重解析点标志import os import stat def is_reparse_point(entry) - bool: 判断 scandir 条目是否为重解析点符号链接、Junction、挂载点 try: st entry.stat(follow_symlinksFalse) except OSError: return True # 拿不到属性就当作危险项跳过 attrs getattr(st, st_file_attributes, 0) return bool(attrs stat.FILE_ATTRIBUTE_REPARSE_POINT)stat.FILE_ATTRIBUTE_REPARSE_POINT这个常量只在 Windows 上存在用getattr兜底是为了让同一份代码在别的系统上不至于直接抛异常。这里有个小技巧拿不到属性时返回True当作危险项跳过而不是False。这是安全设计里的失败关闭原则——不确定的东西一律不碰。把这些链接排除之后判定逻辑还要改一处一个只包含重解析点的目录算不算空我的答案是不算。因为它虽然递归为空但你把它删掉时那个链接本身也会消失而使用者可能还需要它。所以在扫描阶段我会给这类目录单独打一个标记has_reparse报告里归到疑似空但含链接需人工确认那一类跟真正的空目录分开展示。这个分类后来救了我好几次下面第 6 节会讲一个具体案例。3. 动手实现从最小可用版本到能日常用前面两节讲的是想清楚这一节讲写出来。我给的建议是不要一上来就写完整版先写一个 20 行能出结果的脚本拿一个小目录试跑通了再往上加功能。一上来就搞进度条、多线程、报告导出你会在一堆自己写的代码里迷路。3.1 环境准备与项目骨架环境很简单Python 3.8 以上只用标准库一个依赖都不用装。我特意没用第三方库理由是这类工具的受众常常是在别人的机器上临时用装依赖这一步就能劝退一半人。文件夹结构我习惯这样摆empty-dir-scanner/ ├── scanner.py # 核心扫描逻辑可被 import ├── report.py # 报告生成CSV 文本 ├── quarantine.py # 隔离区管理 ├── rules.json # 白名单与排除规则 └── logs/ # 扫描日志与错误清单为什么把扫描和删除分成两个文件因为我想强制自己遵守一个纪律扫描程序不应该有删除能力。scanner.py里出现os.rmdir或者shutil.rmtree就是违规这个约束在代码审查时一眼可见。真正删除的动作放在quarantine.py而它只接受一份已经审阅过的清单文件作为输入。这个物理隔离看起来多余但它挡住了我至少两次手滑——写循环的时候不小心把删除写进了扫描分支因为文件分层IDE 会直接报未导入。配置文件我用的 JSON虽然不如 YAML 好看但它不需要额外解析器。内容大致是{ exclude_patterns: [.git, node_modules, __pycache__], protect_paths: [D:\\工作区, D:\\归档], min_age_days: 7, dry_run: true }min_age_days这个字段值得说一下。它的作用是只报告修改时间早于 N 天前的空目录。为什么加这个因为很多程序在运行时会临时创建目录再删掉你正好在中间那个瞬间扫过去就会误判。给一个时间缓冲能避免大部分这类动了不该动的东西的事故。默认 7 天是我拍的经验值你可以按自己的使用强度调。3.2 核心遍历函数逐行拆解上一节的os.walk版本是骨架真要上生产还得补三样东西排除规则、重解析点标记、以及每个空目录的元信息采集创建时间、最后修改时间、层级深度、父目录。我把它重写成了显式栈版本因为os.walk拿不到scandir条目的缓存元信息还得再stat一次白白多一轮系统调用import os import time from datetime import datetime def scan(root, config, progressNone): 迭代式后序遍历返回 (empty_dirs, skipped, errors) empty_dirs: [{path, depth, mtime, has_reparse}] result {} # path - bool(是否递归为空) meta {} # path - dict empty_dirs [] errors [] visited set() stack [(root, 0, False)] # (路径, 深度, 是否已回退) done 0 while stack: path, depth, is_post stack.pop() if is_post: # 回退阶段判定当前目录 m meta.get(path) if m is None: continue if m[has_file]: result[path] False elif m[has_reparse]: result[path] None # 需人工确认 empty_dirs.append({**m, status: suspect}) elif all(result.get(c) is True for c in m[children]): result[path] True empty_dirs.append({**m, status: empty}) else: result[path] False done 1 if progress and done % 500 0: progress(done, len(stack)) continue # 进入阶段 real os.path.realpath(path) if real in visited: continue visited.add(real) try: entries list(os.scandir(path)) except OSError as e: errors.append({path: path, reason: e.strerror or str(e)}) result[path] False continue info { path: path, depth: depth, has_file: False, has_reparse: False, children: [], mtime: datetime.fromtimestamp( os.stat(path, follow_symlinksFalse).st_mtime), } children [] for e in entries: if is_reparse_point(e): info[has_reparse] True continue if e.is_dir(follow_symlinksFalse): children.append(e.path) else: info[has_file] True info[children] children meta[path] info # 先压回退标记再压子目录保证子目录先出栈 stack.append((path, depth, True)) for c in children: stack.append((c, depth 1, False)) return empty_dirs, done, errors这段代码里最需要理解的是栈的压入顺序。栈是后进先出所以要让回退标记最后被弹出它必须最先被压入。如果你写反了程序不会报错但你会得到一个全空的结果集——所有目录在子目录处理完之前就被判定了。我第一次写这段的时候调了将近两个小时加了一堆 print 才看出来是顺序问题。记住这个口诀回退标记先入栈子目录后入栈弹栈时子目录先出标记最后出。另外visited集合用的是os.path.realpath的结果。这一步防的是硬链接和挂载点造成的重复遍历虽然 Windows 上这种情况比 Linux 少但外接盘、虚拟盘符、网络映射都可能触发。用 realpath 有一点性能开销每次都要解析路径实测在 100 万文件规模下大概多花 5% 的时间我认为这笔保险费值得交。3.3 进度反馈、日志与断点续扫扫大盘的时候没进度反馈是很折磨人的你不知道它是卡住了还是在干活。我的进度显示很简单每处理 500 个目录刷一行已处理 12500 个目录 | 栈内待处理 3400 | 已发现空目录 812 | 用时 00:02:41关键指标选的是栈内待处理而不是剩余百分比。因为磁盘遍历的剩余量在扫之前根本无法预估硬编一个百分比只会得到一个先快后停、最后突然跳到 100% 的假进度条看了更焦虑。栈深度是个真实增长的数字看它能判断程序还在推进。日志我建议一定要写文件而且要分两份一份是空目录清单一份是错误和应用清单。前者是结果后者是免责依据。我在报告头里固定写这么几行扫描根路径D:\ 开始时间2025-01-11 21:03:12 结束时间2025-01-11 21:06:48 目录总数486221 发现空目录12483其中含链接需确认37 无法访问214 跳过白名单192 工具版本0.9.3 参数min_age_days7这份头部信息比结果本身还重要。半年后你回头看某个目录为什么被删了能靠这些参数复现判断过程。断点续扫我这个项目最后没做原因是成本收益不划算。一次全盘扫描也就几分钟真中断了重跑就行。但如果你要扫的是网络位置或者超大冷存储可以加一个简单的检查点每处理 1 万个目录把visited和result序列化到磁盘。我用的是pickle虽然不那么优雅但它是标准库而且这类临时状态文件不怕格式不兼容。3.4 长路径和权限Windows 上绕不过去的两道坎长路径问题。传统上路径总长度限制在 260 个字符超过之后很多操作会直接失败。在深层嵌套的项目目录里比如某些包管理器的依赖树这个限制很容易撞上。现代系统可以通过开启长路径支持来解除具体是注册表里那个LongPathsEnabled开关。但我不建议工具去改系统设置而是在自己的代码里兼容两种情形def to_extended_path(p: str) - str: 给路径加 \\?\ 前缀以绕过长度限制 if p.startswith(\\\\?\\): return p if p.startswith(\\\\): return \\\\?\\UNC\\ p[2:] # 网络路径的特殊写法 return \\\\?\\ p注意网络路径\\server\share要转成\\?\UNC\server\share直接加前缀会失效。这个细节很多示例代码都写错了。实际使用中我的策略是长度超过 240 就自动加前缀短路径保持原样。因为加前缀之后有些 API 的行为会变比如不再自动做路径规范化能不用就不用。权限问题。系统目录、其他用户的配置目录、某些带 ACL 保护的文件夹都会返回拒绝访问。这里的态度要非常明确拒绝访问 ≠ 空。我把它归到未知类报告里单独列出来绝对不参与删除。上面代码里的errors列表就是干这个的。有个反面案例某工具为了扫得干净遇到拒绝访问的目录直接跳过并当成空处理结果把一批受保护目录列出去了使用者一键清理后系统功能异常。这种设计思路我完全不能接受。4. 删除环节才是真正的危险区写到这里扫描部分已经能出结果了。接下来是真正需要谨慎的部分。我的原则只有一条扫描可以激进删除必须保守。4.1 三级策略只报告、进隔离区、真删我把删除分成三个等级默认永远停在第一级级别动作可逆性触发方式L1 报告只生成清单不动文件完全可逆默认行为L2 隔离移动到隔离区目录保留原路径记录可一键回滚显式加--quarantineL3 删除调用os.rmdir删除空目录不可逆仅空目录显式加--purge且二次确认为什么用os.rmdir而不是shutil.rmtree因为os.rmdir只能删空目录目录里只要有一个文件它就报错退出。这是一个天然的安全锁——即使你的判定逻辑出了 bug把非空目录列进了清单rmdir也会拒绝执行而不是把里面的东西一起带走。shutil.rmtree是递归删除用在空目录工具里属于杀鸡用牛刀而且一旦判断失误后果不可收拾。这个选择我从来没犹豫过。还有一个细节删除顺序必须从深到浅。因为删掉最内层之后父目录可能变成空的这时候可以顺势一起删掉这就是所谓的级联清理。上面的os.walk(topdownFalse)天然给出深度优先的顺序直接按列表顺序处理即可。但要注意如果你用的是自己的显式栈版本返回的empty_dirs是按回退顺序排列的也就是深在前、浅在后正好可以直接遍历。4.2 隔离区设计给手滑留一条后路隔离区说白了就是把空目录搬到另一个地方存着。但空目录有个特殊性——你没法直接移动一个空目录再指望它保持结构因为你移动它的时候它在原位置就消失了而原位置的父目录可能因此变空记录就乱了。我的做法是不移动目录本身而是记录一份待恢复清单然后删除。清单里存每个目录的完整路径、创建时间、修改时间、层级深度。回滚的时候按原样重建目录和属性import json, os from datetime import datetime def purge_with_manifest(empty_dirs, manifest_path): deleted [] for item in sorted(empty_dirs, keylambda x: -x[depth]): p item[path] try: os.rmdir(p) # 只删空目录非空会抛异常 deleted.append({ path: p, mtime: item[mtime].isoformat(), }) except OSError as e: print(f[跳过] {p} - {e.strerror}) with open(manifest_path, w, encodingutf-8) as f: json.dump({ created_at: datetime.now().isoformat(), root: empty_dirs[0][path] if empty_dirs else , items: deleted, }, f, ensure_asciiFalse, indent1) print(f已删除 {len(deleted)} 个清单写入 {manifest_path})对应的回滚脚本就是把清单读出来按层级从浅到深依次os.makedirs再用os.utime恢复时间戳def restore(manifest_path): data json.load(open(manifest_path, encodingutf-8)) items sorted(data[items], keylambda x: x[path].count(os.sep)) for it in items: os.makedirs(it[path], exist_okTrue) ts datetime.fromisoformat(it[mtime]).timestamp() os.utime(it[path], (ts, ts)) print(f已恢复 {len(items)} 个目录)这套机制的价值不在于真的能 100% 还原空目录里本来就没东西还原的是结构和时间戳而在于它让删除这个动作变成了可审计的。你知道删了什么、什么时候删的、原来长什么样。有一次我误删了某个项目的目录骨架就是靠这份清单十分钟内全部重建连修改时间都对上了。4.3 白名单与护栏让工具知道哪些地方不能碰护栏我设了四层任何一层命中就跳过第一层路径前缀保护。配置里写的protect_paths做前缀匹配。注意匹配时要处理路径分隔符D:\工作区不该匹配到D:\工作区备份所以要补一个分隔符再比。这个 bug 我在第一版就犯了工作区备份被当成工作区的子路径保护起来了反倒漏掉了一大片。第二层目录名排除。像版本控制目录、依赖目录、缓存目录这类不管空不空都不动。判断方法是取路径的最后一段做精确匹配不要用子串包含——用包含的话my_git_notes会被.git规则误伤。第三层时间门槛。前面说的min_age_days修改时间太新的跳过。这条规则挡掉的是程序正在使用中的临时目录。第四层数量与比例熔断。这个是我加的最有用的一条如果一次扫描发现的空目录超过总目录数的 30%或者绝对数量超过 5 万程序停止并只输出报告拒绝进入删除流程。因为这种量级的异常通常意味着判定逻辑出问题了比如权限大面积失败导致大量目录被误判为空这时候最该做的是人工复核而不是继续执行。5. 性能调优实录从 40 分钟到 3 分钟第一版跑 4TB 机械盘花了 40 多分钟当时我以为这就是磁盘的极限了后来做了几件事同样的盘降到 6 分钟出头换到固态上只要 3 分钟。这部分经验可能比代码本身更有价值。5.1 瓶颈定位先测再改别凭感觉我先做了一件事分段计时。在扫描循环里插桩统计每个阶段的累计耗时阶段首版耗时占比说明os.scandir枚举41%系统调用受磁盘和目录碎片影响os.stat取属性27%每个条目一次调用os.path.join拼路径18%纯 Python 字符串操作集合查询与判定9%结构问题时会暴涨日志与进度输出5%输出太频繁也会拖慢这个表一出来优化方向就很明确了scandir的部分动不了那是磁盘的物理限制但stat和join完全可以省。5.2 具体优化手段与实测收益优化一用scandir的缓存替代单独stat。os.scandir返回的DirEntry对象在 Windows 上会缓存一部分属性调用entry.is_dir()、entry.stat()时不一定触发新的系统调用。我原来的代码是先scandir拿名字再os.path.join拼完整路径再os.stat。改成直接用entry.is_dir(follow_symlinksFalse)之后stat调用量下降了大约七成。这一项单独贡献了将近 30% 的整体提速。优化二延迟拼接完整路径。只有确认需要递归进去的子目录才拼完整路径。文件条目根本不需要拼因为只要发现一个文件当前目录就直接判定为非空。原代码对每个条目都拼路径纯属浪费。优化三日志改成批量刷写。原来每发现一个空目录就print一次输出到控制台的重定向开销在小规模下看不出来十万级的时候就非常明显了。改成累积到 500 条刷一次或者直接写文件缓冲。优化四多线程枚举。这一项要谨慎。文件系统遍历是 IO 密集型理论上多线程有收益但机械盘上基本没收益甚至更慢因为磁头来回寻道。我实测过机械盘 4 线程比单线程慢 12%固态盘 4 线程比单线程快 45%。所以我的实现里加了一个开关默认关闭检测到目标盘是固态再打开。检测方法很土但有效看盘符对应的设备类型拿不到就保守按机械盘处理。优化五跳过明显无关的目录。系统还原目录、休眠文件目录、某些索引目录这些地方你既不该扫也不该删。在进入阶段用前缀快速判断能省掉大量无意义遍历。我在一块系统盘上试过跳过几个大目录之后扫描节点数直接少了一半。把这五项叠加最终的效果是4TB 机械盘 6 分 20 秒1TB 固态 2 分 50 秒扫描节点数 120 万左右。这个成绩我认为够用了再往下优化就得碰底层 API 了性价比不高。6. 常见问题速查与踩过的坑这一节是我最想写的部分。前面讲的都是应该怎么设计这里讲的是实际会怎么坏。6.1 典型问题与处理对照表现象根因处理方式扫描结果里出现明显非空的目录权限失败被当成空处理检查错误清单确认拒绝访问的目录被归为未知程序卡死不动CPU 占用不高遇上了循环链接检查重解析点判定是否生效删除时报目录不是空的判定后目录被程序写入新文件属正常现象跳过即可不要强删扫出来的数量明显偏少路径过长导致枚举失败加\\?\前缀或检查系统长路径开关报告里的中文路径显示乱码文件编码问题统一用 UTF-8 写入读取端也指定编码同一个目录在结果里出现两次通过不同路径访问到同一位置用realpath去重扫描极慢磁盘灯常亮机械盘上开了多线程关掉并发单线程顺序读级联删除删多了父目录本来就不该删加白名单前缀删除后立即停止向上传递时间门槛过滤后仍误删目录被程序 touch 过同时参考创建时间和修改时间隔离清单无法还原清单里存的是相对路径一律存绝对路径表里最后一条我需要多说一句。第一版我为了可移植清单里存的是相对于扫描根的路径。结果有次换了扫描根还原脚本把一百多个目录重建到了错误的位置还得一个个手动清理。这类清单永远存绝对路径可移植性在这个场景里毫无价值。6.2 几条用血换来的经验第一条永远先跑 dry-run而且要看前 50 条。我的工具默认就是 dry-run要真删必须显式加参数。但光这样还不够——很多人扫完直接拖到清单底部按下执行前面的内容根本没看。我现在的习惯是强制看前 50 条和最后 50 条中间随机抽 20 条。为什么因为误判往往集中在特定区域要么是某类特殊结构的目录出现在前部或后部要么是某个特定盘的路径随机抽样能碰到。有次随机抽查就发现一批空目录其实是某个工程的脚手架虽然当时确实是空的但那是构建前生成的删了下一次构建会报奇怪的错。第二条含重解析点的目录单独归类不要混进空目录。前面提过一次这里展开说。某次扫描出来一批空目录其中 37 个带链接标记。我当时没细看差点一起清掉。后来发现其中一个是某软件运行必需的目录占位它靠这个位置存在与否判断运行环境另几个是人为创建的快捷方式目录用来快速跳转到其他盘。这些东西删了不影响数据安全但会让人莫名其妙地某个功能突然不好用了。所以现在这类目录永远走status: suspect分支报告里单独一节标题就叫需人工确认。第三条不要相信回收站。很多人觉得删到回收站就安全了。批量删除几百上千个目录时回收站的操作会很慢而且它本身有自己的容量限制超了之后旧内容会被静默清掉。更要命的是空目录进回收站的行为在不同系统版本上不一致有些版本会直接跳过空目录不进回收站——你以为进了回收站其实已经删了。所以我的方案是完全绕开回收站走自己的隔离清单。第四条给每次运行一个独立的工作目录。日志、清单、错误报告全放到logs/20250111-2103/这种按时间戳命名的目录里。早期我图省事所有运行都往同一个文件里覆盖写结果出了问题时想看上一次的记录早就被覆盖了。这个成本极低收益极高。第五条定期用另一个工具交叉验证结果。我会用 PowerShell 那行命令抽查几个目录看看两边结论是否一致。如果差异超过 5%说明其中一方有问题这时候就该停下来查判定逻辑而不是继续往下走。最后分享一个我自己的使用节奏。我不做定时全盘扫描而是在三种时机手动触发一是重装或大版本升级某软件之后二是做完整盘备份之前避免把垃圾一起备份三是感觉某个盘点起来很卡的时候。每次都是 dry-run、看报告、确认、隔离、观察一周、没问题再清空清单。这个流程听起来啰嗦但一年下来清清淡淡地过了十几次一次事故都没有。慢一点稳一点工具的边界就守住了。
知识建站
内容驱动
阅读友好版式
SEO 精细化
线索转化