系统垃圾清理工具v3.6.2：纯bat脚本打造安全可审计的C盘清理方案

用过 Windows 的人，应该都经历过那种“C 盘怎么又红了”的时刻。Temp 文件、系统更新缓存、浏览器缓存、缩略图、崩溃转储……这些东西日积月累，轻轻松松吃掉十几个 GB。大多数人第一反应是装一个系统垃圾清理工具，可第三方清理软件本身又常常和弹窗广告、全家桶后台驻留绑定在一起。我这些年维护电脑的过程中，一直自己捂着一个小工具——系统垃圾清理工具 v3.6.2，纯 bat 脚本编写，不依赖任何第三方程序，没有服务，没有后台进程，就是一个干干净净的 .bat 文件。它不是最花哨的清理方案，但胜在透明、可控、可审计。这篇文章把这个脚本从设计思路、核心模块、安全机制到踩过的坑全部展开讲一遍，既适合被 C 盘爆红困扰的普通用户，也适合想自己写批处理脚本的运维入门玩家。

1. 为什么是纯 bat，而不是“看起来更高级”的方案

1.1 一台被 C 盘爆满逼出来的需求

这个项目最开始根本没有“版本号”的概念。早几年自己攒了台老机器，系统盘只有 120G，装完常用软件就剩 30G 不到。最夸张的一次，我发现 C 盘只剩 1.8G，打开系统盘一看，Windows 更新缓存占了 8G，用户临时目录占了 5G，回收站里还躺着几个装系统时留下的镜像文件。那时候我就想做一件事：写一个能一键清理垃圾的工具，但这个工具必须完全看得懂、信得过。

后来帮别人维护电脑的次数多了，我发现大多数人根本不敢自己删系统盘里的文件。不是不会操作，而是不知道哪个能删、哪个不能删。普通用户面对 C:\Windows 这种目录，本能反应就是不能动。而第三方清理软件弹窗推荐“优化加速”“开机管理”，反而让人更不放心。所以我决定写一套纯 bat 脚本——.bat 文件就是纯文本，任何文件管理器都能打开看内容，每一行命令在干什么都能读明白。这种“源代码透明”带来的信任感，是任何绿色破解版清理工具都给不了的。

1.2 bat、PowerShell、第三方工具到底怎么选

很多人会问：PowerShell 明显更强，能递归处理对象、能调用 .NET 类库，为什么非要用 bat？我的答案很现实：bat 门槛最低，兼容性最好，行为最可预期。PowerShell 在 Win7 时代还需要单独安装，Win10 以后虽然系统自带，但一台机器上可能有多种执行策略限制，双击 .ps1 文件默认是打开记事本而不是执行。bat 则不同，双击就能跑，右键管理员运行就能提权，几乎没有任何前置条件。

第三方清理工具在这三者里功能最强，界面最友好，但问题也最严重：你永远不知道它除了清理还做了什么。有些工具后台常驻，有些捆绑浏览器主页，有些甚至会上传你的文件列表做“个性化推荐”。相比之下，bat 脚本里的每一行 del、rd、robocopy 都是白纸黑字，删哪个目录、调哪个系统接口，一眼就能看明白。我选 bat 不是因为它最强，而是因为它最“笨”——笨到每一步都藏不了猫腻。

表格对比更直观：

这三种方案不是绝对对立，v3.6.2 里有一个小模块就内部调用了系统自带的 PowerShell 来清空回收站。纯 bat 不等于完全拒绝别的工具，而是“主体逻辑必须 bat 可控。真正需要调用系统组件的时候，调用的是系统自带的、干净的接口”。

1.3 纯 bat 的边界，我必须承认的事

蝙蝠脚本在处理文本、正则表达式、Unicode 编码这些场景里非常别扭，这是事实。比如 for 循环里想统计一个目录下有多少个文件，就得写嵌套 for，再配合变量延迟展开才能拿到结果，远没有 PowerShell 的 (Get-ChildItem).Count 来得直接。

但垃圾清理这个场景恰好落在 bat 的舒适区里：它处理的是文件系统的删除操作，本质是删目录、删文件、停服务再启动。这些操作不需要高深的逻辑，只需要一个可靠的“路径清单”和“异常处理机制”。脚本的复杂度不在语言本身，而在对 Windows 系统目录结构的理解。我承认 bat 写配置解析很痛苦，所以我干脆不用解析，直接在脚本头部用 set 定义开关变量，让用户修改更简单。这套工具能迭代到 v3.6.2，恰恰是因为我在设计上避开了 bat 的弱项，把它的强项发挥到了极致。

2. 脚本核心结构：按模块清掉每一类垃圾

2.1 用一个主流程串起所有清理模块

v3.6.2 的整体结构可以拆成两层：主流程和清理模块。主流程负责三件事：检测管理员权限、读取配置、按顺序调用各清理模块。清理模块则各自独立，比如清理临时文件的模块只管临时文件，清理更新缓存的模块只管更新缓存，互不干扰。

这种模块化设计是被教训逼出来的。早期版本把所有删除命令堆在一个大段里，只要有一处路径写错，整个脚本的执行结果就很难追溯。后来重构成模块化以后，每个模块输出自己清理了多少个文件、释放了多少空间、遇到哪些错误，主流程把结果汇总写入日志。这样一来，哪块工作没做到位，看日志一眼就能定位。

主流程的伪结构大概是这样：

@echo off setlocal EnableDelayedExpansion call :check_admin call :load_config call :clean_temp call :clean_update_cache call :clean_recycle call :clean_thumbnail call :write_log exit /b

每个模块是独立标签，主流程只负责调用和收集结果。这个结构的好处是：如果某一个清理逻辑需要调整，只需要改对应模块，完全不影响其他部分。后期排查问题和迭代版本的时候，这个“拆开”的动作省了太多心。

2.2 临时文件和缓存：robocopy 清目录比 del 更稳

临时文件是所有垃圾里最无害、也是体积最容易膨胀的一类。用户临时目录、Windows 临时目录、缩略图缓存、崩溃转储，这些都是可以放心清理的。但是具体怎么删，里面有个很多人不知道的技巧。

大多数人写 bat 清理目录，第一反应是 del /q /s 加 rd /s /q。这个组合在目录层级浅的时候没问题，一旦遇到超长路径、只读文件、或者目录权限被特殊设置过，就会报“访问拒绝”或者“文件名太长”，然后整个清理流程被卡住。

我在 v3 之后把核心目录的清理方式改成了 robocopy 镜像法。原理很简单：先建一个空目录，然后让 robocopy 把这个空目录“镜像”到目标目录上。镜像的意思是让目标目录变得和源目录一模一样，源目录是空的，那么目标目录里的所有内容都会被移除。

set "EMPTY=%SystemDrive%\_empty_tmp_" if not exist "%EMPTY%" mkdir "%EMPTY%" robocopy "%EMPTY%" "%TEMP%" /MIR /R:1 /W:1 /NFL /NDL /NJH /NJS /NP >nul 2>&1 rd /s /q "%EMPTY%" >nul 2>&1

robocopy 对长路径、只读文件、系统文件的容错能力比 del 强得多，而且 /R:1 /W:1 表示只重试一次、等待一秒，不会被一个顽固文件拖住太久。这是我在清理 C:\Windows\Temp 时踩了无数次坑之后得出来的经验，网上很多清理脚本会忽略这个细节，导致用户跑完脚本发现临时目录还是满的，其实问题就出在删除过程被中断了。

2.3 系统更新缓存：停服务再删才不会被占用

Windows 更新缓存是 C 盘空间的吞金兽。系统下载的补丁包、升级包会存放在 C:\Windows\SoftwareDistribution\Download 目录下，有些机器的这个目录能膨胀到 8G 甚至更大。

难点在于：这个目录里的文件经常被 Windows Update 服务占用，直接删除会报“另一个程序正在使用此文件”。正确顺序应该是先停掉 Windows Update 服务和后台智能传输服务，删除文件，然后再把服务启动回来。

net stop wuauserv >nul 2>&1 net stop bits >nul 2>&1 attrib -r -s -h "%SystemRoot%\SoftwareDistribution\Download\*.*" /s /d >nul 2>&1 robocopy "%EMPTY%" "%SystemRoot%\SoftwareDistribution\Download" /MIR /R:1 /W:1 /NFL /NDL /NJH /NJS /NP >nul 2>&1 net start bits >nul 2>&1 net start wuauserv >nul 2>&1

这里有一个很多人容易误解的地方：停掉服务以后奔跑的更新可能会被中断，但那只是当前的更新检查/下载动作被打断，重启服务后系统会重新检查和下载，不会对系统本身造成破坏。但如果运气比较差，系统正处于“正在安装更新”的阶段，我建议不要强行执行这个模块，等更新完成后再清理。所以 v3.6.2 默认只在检测到 Windows 更新服务处于停止状态时才执行这个模块，如果服务正在忙，就跳过并把原因写入日志。

补充一个绝对不能删的目录：C:\Windows\Installer。很多清理工具为了省空间会去动这里，但里面存的是已安装软件的补丁和卸载信息，删掉后会导致部分软件无法卸载、无法升级甚至无法运行。这个目录放进我的“绝对禁止”列表。

2.4 回收站与缩略图：这两个最容易被忽视

回收站占用的空间往往被很多人忽略。大家总觉得“装进回收站的文件就不占地方了”，事实上回收站的文件依然占据磁盘空间，只不过对用户不可见。清空回收站最稳的方式不是直接 del 回收站的物理目录，而是调用系统接口执行一次“清空回收站”操作。

v3.6.2 里有一段代码是内部调用 PowerShell 的，就一行：

powershell -NoProfile -Command "Clear-RecycleBin -Force -ErrorAction SilentlyContinue"

这一行等价于你在桌面上右键回收站、选择清空，但它不依赖窗口交互。为什么不直接删除 C:$Recycle.Bin 目录？因为直接删目录可能破坏回收站的索引结构，个别情况下会导致“回收站损坏”的提示，得不偿失。调用官方接口是最省心的办法。

缩略图缓存是另外一个容易被忽视的点。资源管理器为了显示文件夹缩略图，会在每个用户的 LocalLow、AppData 目录下生成 thumbcache 文件。对机械硬盘用户来说，缩略图缓存能加快浏览速度，但实际收益有限；对 SSD 用户来说，这个缓存纯粹就是空间负担。只要探访过大量图片和视频，这个缓存很容易超过 1G。删除的路径是 %LOCALAPPDATA%\Microsoft\Windows\Explorer 下的 thumbcache_*.db，脚本会在资源管理器进程退出后尝试清理——注意，如果 explorer.exe 正在运行，直接删不掉，我一般是提示用户先关闭所有资源管理器窗口，或者用 taskkill 重启资源管理器，但这个操作对正在工作的人来说有点粗暴，所以默认设置为“检测到 explorer 占用就跳过”。

3. 安全设计是这套脚本的命根子

3.1 绝对不碰的目录清单

v3.6.2 里有一个白名单保护机制：脚本维护了一份“绝对禁止清理”的路径清单。这些路径包括系统目录、软件安装目录、用户文档目录、下载目录等。在清理任何一个模块之前，脚本会先把目标路径和禁止清单做比对，一旦命中就直接终止该模块并写入警告日志，绝不含糊。

这个保护机制不是我一开始就想到的，而是吃过亏。早期版本的思路是“见一个清一个”，结果在帮人维护时，差点把桌面上一份写了一半的毕业论文当成临时文件处理。虽然最后因为文件正被 Word 占用逃过一劫，但那次经历让我醒悟：清理工具的职责不是判断所有文件的价值，而是只清理那些“系统自己都会在特定时间清理”的东西。

禁止清单的核心包括：

• C:\Windows、C:\Windows\System32、C:\Windows\SysWOW64，这些目录动一个文件都可能出大问题。
• C:\Users 下的桌面、文档、图片、下载、音乐等库文件夹，用户数据永远不在清理范围内。
• C:\Program Files 和 C:\Program Files (x86)，已经安装的软件目录不清理。
• C:\Windows\Installer 和 C:\Windows\WinSxS，前者影响软件卸载，后者是系统组件存储，删了可能导致系统更新失败。

这些目录全凭经验整理出来的。网上有些“清理 C 盘”文章让你删 WinSxS 里的东西，纯属误导。WinSxS 里的硬链接结构非常复杂，手动删几个文件表面上释放了空间，实际上会破坏系统更新机制，甚至导致某些系统组件不可用。我的原则很简单：宁可漏删，不可多删。

3.2 干跑模式：先扫描，后删除

v3.6.2 里最实用的功能之一是“干跑模式”。干跑模式下，脚本不会删除任何文件，只是把每个模块将删除的文件数量、占用空间、具体路径清单统计出来，输出到日志和屏幕上。

这个功能为什么重要？因为清理工具最容易出现误判的场景，恰恰是用户觉得“它应该很安全”的时候。某些软件临时产生的数据可能包含用户未保存的编辑状态，某些日志文件可能正是故障排查的关键线索。直接删除的后果不可逆，而干跑模式让用户在动手之前先看到“将要发生什么”。你可以先跑一遍，检查待清理列表，确认没问题再执行正式清理。

我在脚本里加了一个开关参数：/simulate。命令行运行 cleaner.bat /simulate 就能进入干跑模式。如果检测到硬盘剩余空间小于某个阈值，脚本还会主动建议用户先开干跑模式确认风险。这个设计是真真切切从实践中长出来的：一次系统更新失败后，用户本来想靠日志排查问题，结果被某个清理工具顺带把日志目录清空了，故障就没法定位了。从那以后，我做的清理工具都必须支持这种“先看清，再动手”的流程。

3.3 隔离区与日志：给每一次删除留退路

v3.6.x 系列做了一个很大的改动：引入隔离区机制。普通垃圾文件（比如临时缓存、下载失败的残留）直接删除，但那些“边界模糊”的文件，会先移动到隔离区目录，而不是直接永久删除。这个目录位于系统临时分区下，名字是隔离区，脚本会在完成清理后的 72 小时（可配置）后自动清空隔离区中的内容。如果用户发现问题，可以从隔离区把文件手动放回去。

这个机制解决了清理工具最尴尬的问题：你永远没办法保证判断 100% 正确。有了隔离区，至少给了自己和用户一个缓冲期。比如某个软件的配置缓存被当成垃圾隔离了，软件还能正常用，那基本可以确定该缓存确实没用；如果软件异常，那就去隔离区恢复对应文件。

另外，每一次清理运行都会生成日志文件。日志记录的内容包括：执行时间、运行模式、每个模块清理的文件数和大小、耗时、错误列表、禁止目录的命中记录。清理完以后，脚本的当前目录下会生成一个像 clean_log_20250217_182233.log 这样的文件。这个日志在排查问题时就是最重要的线索——你遇到“清理后 X 软件不正常了”的情况，只要打开日志看一遍，就能知道实际删了哪些路径，比凭空猜要高效得多。

3.4 权限提升与异常拦截

垃圾清理本来就是一个需要管理员权限的操作。系统临时目录、Windows 更新缓存这些都是普通权限无法删除的。所以 v3.6.2 在启动时第一步就是检测当前是否有管理员权限，检测方法是尝试访问一个只有管理员才能读的控制信息，其实是最土的办法：net session。

net session >nul 2>&1 if %errorlevel% neq 0 ( powershell -Command "Start-Process -FilePath '%~f0' -Verb RunAs" exit /b )

没有管理员权限就自动调用 UAC 提权重启自己，有权限就继续执行。这个处理方式避免了用户手动右键选“以管理员身份运行”这一步，对小白用户更友好，也让脚本在计划任务中能直接以 SYSTEM 权限运行。

异常拦截方面，脚本在每一处删除操作后都检查 errorlevel，如果返回非 0，就把失败路径记录到一个环境变量里，最后统一写入日志。脚本里有大量“if not exist”判断，目的是在删除前确认目标路径存在且确实属于预期位置。比如清理用户目录时，要求路径包含 %USERPROFILE%\AppData\Local 前缀，否则直接放弃执行，防止因为环境变量异常导致误删其他目录。

4. 实操过程：从拿到脚本到完成一次清理

4.1 配置文件里的 6 个关键开关

v3.6.2 根目录下有一个 config 区域，在脚本开头用 set 命令定义了若干个开关。用户不需要懂 bat 语法，只需要改 0 和 1。这 6 个开关分别是：

这些开关放在文件头部 10 行以内，打开脚本第一眼就能看到。不用去理解复杂配置语法，也不需要装什么编辑器，记事本就能改。把不想清理的模块改成 0，脚本就会跳过，就这么简单。

4.2 双击运行与命令行参数

配置改好之后，双击 cleaner.bat 就会开始执行。会在屏幕上看到类似这样的输出：

[信息] 正在检查管理员权限... 已获得管理员权限 [信息] 当前运行模式：正式清理 [模块1/4] 正在清理临时目录... 已清理 1287 个文件，释放约 1.2 GB [模块2/4] 正在清理系统更新缓存... 更新服务忙碌，本次跳过，原因已写入日志 [模块3/4] 正在清空回收站... 已释放 3.5 GB [模块4/4] 正在清理缩略图缓存... 已清理 56 个文件，释放约 380 MB [完成] 本次清理共释放约 5.1 GB，耗时 47 秒

如果你不想它弹窗交互，可以用命令行参数运行：cleaner.bat /quiet 静默模式，不输出屏幕信息，只写日志；cleaner.bat /simulate 干跑模式，只统计不删除；cleaner.bat /log 执行结束后直接打开日志文件。组合使用可以做到完全无人值守。

有一点必须强调：用 /quiet 模式之前，至少先手动完整跑过一次，确认配置文件没有把不该开的模块打开。静默模式不是给你第一次运行准备的，是给你 30 台机器批量维护的时候准备的。

4.3 计划任务实现每周自动清理

很多人的电脑不是不想清理，是每次都忘了。手动画一个月历提醒又不太现实。最好的办法是交给计划任务。

用系统自带的 schtasks 命令就能建一个每周自动执行的任务，不需要额外工具。示例命令：

schtasks /Create /TN "WeeklySystemClean" /TR "C:\Scripts\cleaner.bat /quiet" /SC WEEKLY /D SUN /ST 03:00 /RU SYSTEM /RL HIGHEST

这条命令创建了一个每周日早上 3 点执行的任务，任务以 SYSTEM 身份运行，拥有最高权限。/quiet 参数保证不会弹出任何窗口，日志会安静地记录每次清理结果。第二天早上打开日志看一眼，就能知道系统在空档期被清理了多少。

这里有个经验：把任务时间安排在凌晨 2 点到 4 点之间，这个时间段绝大多数用户的机器都在空闲，文件被占用的概率最低，清理成功率最高。如果你用的是笔记本且经常睡眠，建议计划任务设置里勾选“如果计算机正使用电池，则停止”，避免它半夜自动清理把没保存的文档搞出状况——虽然脚本本身不碰用户文档，但对系统的操作还是越保守越好。

5. 从 v1.0 到 v3.6.2：踩坑史就是版本史

5.1 v1 时代：敢删，也敢死

第一版脚本非常简单，核心只有三五条命令。删临时文件夹、删更新缓存、清空回收站，加起来不到 1KB。那个版本处理过很多日常问题，但也出过几次让人后背发凉的状况。

最严重的一次，环境变量 %TEMP% 在某个奇怪的软件在安装时被改到了 D 盘某目录，脚本没有做路径前缀校验，直接按默认逻辑执行清理，结果把那个软件自己的“临时工作目录”给清了，软件启动后数据全部丢失。那次之后我才意识到：清理工具最重要的不是清理能力，而是不敢动的东西绝对不碰。v1 版本没有白名单，没有模块独立，没有日志，每一次执行都是在赌运气。

5.2 v2 加入安全层，v3 重构成模块

v2 版本最大的变化是引入了两个东西：管理员权限检测和白名单保护。不再用 del 直接删用户目录，而是列出一个允许清理的路径集合，只有命中集合的目录才会被处理。这个版本之后，再也没有发生过那种“软件数据被连带清掉”的事故，但代码结构依然很乱，所有清理逻辑堆在一起，想要单独关掉某一项清理，只能在代码里去注释掉对应行。

v3 是一次彻底的重构。所有清理逻辑拆成了独立函数，加了配置文件区，加了日志模块。这次重构之后，脚本才真正意义上成为一个可持续演进的项目。模块化带来的好处立竿见影：修复某一个清理逻辑的表格时，不会影响其他模块，测试成本大大降低。

5.3 3.6.x 系列：为什么我敢说稳定

v3.6.2 这个版本号是基于 3.6.x 线上线下的多次实测沉淀下来的。3.6.x 系列主要修了三类问题：一是补齐了 Windows 10/11 某些版本里目录路径变化的问题（比如 OneDrive 占位文件、新版 Edge 的缓存位置），二是修复了批处理里变量延迟展开导致计数不准确的问题，三是将清理失败文件的处理全部改为“记录并跳过”，不再因为单个文件占用而导致整个模块中断。

这些修正看起来不显眼，但真实运行的时候非常提升体验。比如变量延迟展开，如果不使用 setlocal EnableDelayedExpansion 和 !var! 语法，for 循环里累计的计数永远是第一次循环之后的值，清理报告就会显示“清理了 0 个文件”，让人误以为脚本没干活。这种细节问题只有真实运行多个版本才会发现。3.6.2 发布前，我在三台配置不同的机器上连续测试了两周，确认各模块的跳过率在可接受范围内，才敢把版本定为稳定版。

6. 常见问题与排查技巧实录

6.1 文件占用删不掉，怎么办

清理过程中最常见的报错就是“文件正在被另一进程使用”。如果你的浏览器正在运行，它的缓存目录是肯定删不干净的。脚本的设计是跳过这类文件并记录到日志，但如果你想更彻底地清理，最好先退出浏览器、资源管理器、视频播放器这类程序，再执行清理。

一个实用技巧：如果你不确定是哪个进程占用了文件，可以用系统自带工具 resource monitor 查看文件句柄——在开始菜单搜索“资源监视器”，切到 CPU 选项卡，在关联的句柄里输入文件路径。不过在批处理内部做这件事比较复杂，所以我更推荐靠调整清理时间来避开文件占用：大部分人的电脑在早上刚开机时，后台进程最少，清理成功率最高。

6.2 安全软件把脚本拦了，怎么办

纯 bat 脚本被安全软件误报是常见事。原因很简单：脚本没有数字签名，文件行为特征（批量删除、停服务）又符合“高风险操作”的判定标准。我在实际使用中见过不止一次误报。

正确处理方式不是把系统安全机制整个关掉，而是把脚本所在目录加入安全软件的信任区。操作路径一般是在安全软件的“排除项”里添加该目录。同时建议你确认一下脚本内容和网上流传的版本是否一致——如果你下载的脚本被二次修改过，那确实该警惕。我的原则是：脚本源码必须公开可读，包含详细注释，并且从不加密混淆。一个连代码都不敢给你看的清理工具，无论它宣称自己多强大，都不值得信任。

6.3 中文乱码、变量延迟、路径带空格

bat 文件的中文编码问题让很多人头大。如果你把脚本保存为 UTF-8 编码，在 Windows 默认的 GBK 代码页下运行，echo 出来的中文可能全是乱码。这不是脚本逻辑问题，而是编码不一致。解决方式有两种：一是统一保存为 ANSI/GBK 编码；二是在脚本开头加一行 chcp 65001 切换代码页为 UTF-8。我自己倾向第一种方案，因为 chcp 65001 在某些老版本 Windows 上会影响命令输出格式，反而引入新问题。

路径带空格是另一个高频坑。你的用户名如果是 “Zhang San”，用户目录路径就带空格。bat 里处理带空格路径必须加引号，否则命令会把路径截断。还有一个容易忽略的坑是变量延迟展开：在 for 循环内部访问循环外赋值的变量时，必须用 !var! 才能拿到最新值，用 %var% 会拿到循环开始前的值。这个语法细节是排查清理计数不准的关键。

6.4 清理频率怎么定才合适

很多人误以为垃圾清理越频繁越好。其实不然。系统更新缓存被频繁清理，会导致每次检查更新都要重新下载部分文件，反而增加带宽和时间消耗。缩略图缓存被频繁清理，资源管理器每次打开图片文件夹都要重新生成缩略图，视觉上就是“越清理越卡”。

根据我的维护经验，保持每周清理一次是比较合理的节奏。工作日产生的临时文件在周末清理掉，既不会堆积太多，也不至于频繁清缓存。如果你某个时间段频繁安装软件、更新系统，临时加跑一次也没问题。核心原则是：清理是为了让系统恢复流畅，不是为了给系统找事干。过度清理对系统健康状况的影响，有时候比不清理还大。

这套脚本从 v1 走到 v3.6.2，最深的体会是：清理工具的价值不在“删得快”，而在“删得准”。技术含量最高的部分不是那几十行删除命令，而是背后对“什么文件能安全删除”的判断体系。我到现在每次新增一个清理模块，都先往“禁止清单”里过一遍，问自己三个问题：这个路径会包含用户数据吗？软件依赖它吗？系统能自行重建它吗？三个问题都回答“不会”，它才有资格进入清理列表。抱着这种敬畏心写代码，你的清理脚本才能真正帮到人，而不是变成另一颗炸弹。