Windows临时文件清理全攻略：从手动清理到自动化脚本

1. 临时文件为什么越清越多：先搞懂Windows的缓存机制

不知道你有没有过这种经历：C盘又标红了，打开磁盘清理工具一顿操作，删了几个G，心里踏实了。结果过了一周，系统托盘又弹“磁盘空间不足”，打开一看C盘又满了。这不是Windows在跟你作对，而是你一直在清理结果，却没清理“原因”。

临时文件的本质是“缓存”和“中间产物”。Windows和各类软件在运行过程中，会频繁把一些需要快速读取的数据、解压过程产生的碎片、更新下载的安装包、索引服务生成的临时库，全部丢到一个约定好的目录里。这个目录，就是我们常说的%TEMP%和C:\Windows\Temp。

Windows为什么要这么干？你可以把临时目录理解成厨房的操作台。厨师做菜的时候，不可能每切一刀就跑去储藏室拿一次食材，他会先把这顿要用的东西全部放在手边，做完一道菜再收拾台面。Windows和软件同理，把要用的中间文件先堆在台上，是为了提高处理速度。问题在于，这台面的储物能力是有限的，而且很多软件用完台面之后不收拾，直接换下一道菜，久而久之，台上堆的东西比储藏室还多。

很多人的误区是，临时文件只是浏览器缓存、安装包残留。实际上，真正占据C盘空间的临时文件，远不止这些。在Windows 11中，至少有以下几类常见的“临时文件大户”：

• 软件运行产生的临时文件：存储路径默认在C:\Users\用户名\AppData\Local\Temp，各类软件运行时解压的组件、生成的日志、崩溃转储文件，都会往这里堆。最典型的就是大型设计软件、视频处理软件、AI绘图工具（比如ComfyUI），它们在工作时会产生数GB甚至数十GB的中间缓存。
• Windows更新缓存：更新下载的安装包会被暂存在C:\Windows\SoftwareDistribution\Download，这些安装包是完整的“安装源文件”，下载一个几GB的版本更新，这里就会留下同等大小的文件。更新装完后，系统不会自动清理这些文件。
• 传递优化缓存：这个很多人在Windows 11里才注意到。系统默认开启“允许从其他电脑下载更新”，这部分缓存文件被存放在C:\Windows\SoftwareDistribution\DeliveryOptimization，如果你更新频率较高，这里也能攒出不少空间占用。
• 系统还原点与卷影副本：虽然不算严格的临时文件，但确实被许多人误归为“临时”一类。它们存放在系统卷的隐藏目录里，每个还原点可能占用数GB空间。
• 软件安装器的残留：很多安装器在安装完毕后并不会删除自己解压出来的临时文件，特别是那些需要联网下载再解压安装的国产软件，装一次就存一份，重新安装就又多一份。
• 缩略图缓存、字体缓存、图标缓存：这一类体积不大，但胜在数量多、更新频繁，在资源管理器里浏览大量图片文件的用户，会看到这类缓存持续增长。

手动清理之所以“清不干净”，核心原因在于：你只清理了表面的%TEMP%目录，但Windows更新缓存、传递优化缓存、软件安装残留这些真正的“体积大户”，默认磁盘清理工具并不会全部覆盖到。另一个原因是，很多临时文件正被系统或后台进程占用，磁盘清理工具会直接跳过这些文件，你表面上点了“清理”，实际上只有部分文件被删除。

所以，要做一套真正靠得住的临时文件清理方案，第一步不是找脚本，而是先把自己的系统“案发现场”摸清楚。你至少要知道：这份清理清单覆盖哪些目录、哪些文件会被跳过、哪些文件不能碰。这一步走完，后面的自动化才有意义。

2. 手动清理的底线：这些目录能删，这些千万别碰

在写自动化脚本之前，我建议你先把系统自带的清理工具和手动目录清理跑一遍。不是说手动清理能解决多少空间，而是通过手动操作，你能直观地看到哪些文件是真正冗余的、哪些文件删了会出问题。这套经验，会直接影响你在自动化脚本里设计“安全边界”。

2.1 系统自带磁盘清理工具的正确用法

大多数人用磁盘清理，都是直接在搜索框里输入“磁盘清理”，然后选C盘直接扫描，哪个选项勾选体积大就勾哪个。这个用法，只能清理到Windows认为“绝对安全”的文件，而且很多选项默认不展开。

正确的用法是：先运行磁盘清理工具扫描一次，不管结果如何，先关掉。然后以管理员身份打开命令提示符，运行以下命令，让Windows在下次扫描时把设置界面完全展开：

bash复制cleanmgr /sageset:1

sageset的意思是“保存清理设置”。执行后，系统会弹出一个包含全部清理选项的窗口——注意，这里比平时看到的“磁盘清理”选项卡多出很多选项，包括“Windows 更新清理”“旧版 Windows 安装文件”“传递优化文件”“设备驱动程序包”等。把你能看懂的、确认没用的选项全部勾上（比如“临时文件”“缩略图”“传递优化文件”），然后点击确定。

之后再次执行：

bash复制cleanmgr /sagerun:1

系统会按照刚才保存的配置开始清理。这个过程比普通扫描清理要彻底得多，能多删出2～5GB空间，对老系统尤其明显。如果你已经安装了较新的Windows 11版本，也可以直接在“设置→系统→存储→临时文件”里手动勾选清理，这里的展示形式更友好，但清理范围不如sageset全部选项那么完整。

2.2 值得手动删除的目录清单

系统自带的清理工具跑完之后，如果你还想深度清理，可以按以下目录逐个检查。每个目录删除前，建议先查看体积，避免误删。

• 用户临时目录：C:\Users\用户名\AppData\Local\Temp，这个目录下的文件原则上都可以删除，但被占用的文件会提示失败，通常选择跳过。
• 系统临时目录：C:\Windows\Temp，同理，多数文件可删，但可能会遇到权限提示。以管理员身份操作时，绝大多数文件可以删除。
• Windows更新下载缓存目录：C:\Windows\SoftwareDistribution\Download，这个目录存放的是更新安装包，更新都装完后，这里的文件已经没用，可以直接清空。删除时记得保留SoftwareDistribution这个文件夹本身，只删内部文件。
• 传递优化目录：C:\Windows\SoftwareDistribution\DeliveryOptimization，这个目录下的缓存文件是之前从其他电脑获取的更新分块，删除不会影响后续更新。
• Windows.old目录：如果系统做过大版本升级或重装，C:\Windows.old可能会占掉10GB以上，这是旧系统的完整备份。确认新系统稳定运行之后，正常应该用“设置→系统→存储→临时文件”里的“以前的 Windows 安装文件”来清理，不建议直接手动删目录，因为可能会有权限残留问题。
• 崩溃转储文件：路径在C:\Windows\Minidump，这些是蓝屏或软件崩溃时生成的调试文件。如果你不是做驱动开发、也不打算排查蓝屏问题，可以直接删除。看到这些文件，往往说明系统有过崩溃记录。

2.3 三种坚决不能乱删的东西

第一，C:\Windows\WinSxS目录。这个目录经常被不熟悉系统结构的用户当成临时文件清理对象，最终导致系统组件损坏、更新失败。WinSxS是并行组件存储，存放着系统运行所需的所有关键组件版本，绝对不能用资源管理器直接删除。Windows 11中，该目录的大小可以通过DISM /Online /Cleanup-Image /StartComponentCleanup命令安全压缩，但这不是“删除”操作，而是组件清除机制。

第二，C:\System Volume Information。这是系统还原和卷影副本的存储位置，直接删会导致系统还原功能失效。如果确实需要释放空间，应该使用“系统保护”设置里的“删除”按钮，或通过存储感知清理。

第三，各类软件正在使用的“临时工作目录”。很多设计软件、开发工具会把当前工程的临时文件放在%TEMP%下，但文件正在被进程锁定。你即便强制删除了文件，软件在下次保存或导出时会因为找不到临时文件而报错，甚至导致未保存的工作丢失。这就是为什么清理脚本需要对“被占用文件”有一颗宽容心：能删就删，删不掉就跳过，绝不“强制删除所有”。

手动清理这一步做完，你应该对系统里临时文件的分布有了直观感受。接下来，就可以把这些操作固化成脚本，进入自动化阶段了。

3. 批处理脚本：把高频清理动作变成一键执行

手动清理适合偶尔做一次，但大多数人希望一劳永逸。我的做法是，先写一个批处理脚本，把上面这些手动操作全部封装进去，然后通过计划任务定时执行。脚本本身不复杂，难的是设计边界和应对各种意外情况。

3.1 脚本设计思路与安全边界

写清理脚本前，我给自己定了三条铁律：

• 只清理明确安全的目录，不碰任何带“未知数”的文件。
• 删除失败不报红、不死循环，删不掉的直接跳过。
• 清理动作要生成日志，方便事后检查到底删了什么、哪些没能删掉。

基于这三条，脚本的架构分为五个核心模块：清理用户临时文件、清理系统临时文件、清理Windows更新缓存、清理传递优化缓存、清理崩溃转储。每一模块都带一个“目录存在性判断”和“删除结果追加日志”的逻辑。

为什么要把更新缓存和传递优化缓存单独分模块？因为这两个目录在自动化场景中比较特殊。比如，如果你计划任务设定的时间是每周末，而系统恰好在周五下载了新的更新安装包，但更新还没安装完，此时清理SoftwareDistribution\Download会导致下一个更新阶段找不到包，从而报错。因此，稳妥的做法是，先判断系统更新服务是否正在运行，如果运行中则跳过该模块，并在日志里注明原因。

3.2 完整脚本及逐段注释

下面是我在Windows 11 24H2和26H1预览版上均验证过的脚本，你可以直接复制保存为CleanTemp.bat，右键“以管理员身份运行”测试。注意，脚本里的路径用%USERNAME%代替了具体的用户名，如果当前登录用户是标准账户，需要用管理员账户执行。

batch复制@echo off
setlocal enabledelayedexpansion
set LOGFILE=C:\TempCleanLog\CleanTemp_%date:~0,4%%date:~5,2%%date:~8,2%.log
if not exist C:\TempCleanLog mkdir C:\TempCleanLog
echo ================================================ >> "%LOGFILE%"
echo 临时文件清理开始：%date% %time% >> "%LOGFILE%"
echo ================================================ >> "%LOGFILE%"

rem 模块一：用户临时文件
if exist "%TEMP%" (
    echo [1/5] 正在清理用户临时文件... >> "%LOGFILE%"
    for /d %%i in ("%TEMP%\*") do rd /s /q "%%i" 2>>"%LOGFILE%" & if not exist "%%i" (echo   删除目录成功：%%i >> "%LOGFILE%")
    del /f /q "%TEMP%\*" 2>>"%LOGFILE%"
    echo [1/5] 用户临时文件清理完成 >> "%LOGFILE%"
)

rem 模块二：系统临时文件
if exist "C:\Windows\Temp" (
    echo [2/5] 正在清理系统临时文件... >> "%LOGFILE%"
    for /d %%i in ("C:\Windows\Temp\*") do rd /s /q "%%i" 2>>"%LOGFILE%"
    del /f /q "C:\Windows\Temp\*" 2>>"%LOGFILE%"
    echo [2/5] 系统临时文件清理完成 >> "%LOGFILE%"
)

rem 模块三：Windows更新缓存（需检测更新服务状态）
sc query wuauserv | find "STOPPED" >nul
if %errorlevel% equ 0 (
    echo [3/5] Windows更新服务已停止，开始清理更新缓存... >> "%LOGFILE%"
    if exist "C:\Windows\SoftwareDistribution\Download" (
        for /d %%i in ("C:\Windows\SoftwareDistribution\Download\*") do rd /s /q "%%i" 2>>"%LOGFILE%"
        del /f /q "C:\Windows\SoftwareDistribution\Download\*" 2>>"%LOGFILE%"
    )
    echo [3/5] 更新缓存清理完成 >> "%LOGFILE%"
) else (
    echo [3/5] Windows更新服务运行中，跳过更新缓存清理 >> "%LOGFILE%"
)

rem 模块四：传递优化缓存
if exist "C:\Windows\SoftwareDistribution\DeliveryOptimization" (
    echo [4/5] 正在清理传递优化缓存... >> "%LOGFILE%"
    for /d %%i in ("C:\Windows\SoftwareDistribution\DeliveryOptimization\*") do rd /s /q "%%i" 2>>"%LOGFILE%"
    del /f /q "C:\Windows\SoftwareDistribution\DeliveryOptimization\*" 2>>"%LOGFILE%"
    echo [4/5] 传递优化缓存清理完成 >> "%LOGFILE%"
)

rem 模块五：崩溃转储文件
if exist "C:\Windows\Minidump" (
    echo [5/5] 正在清理崩溃转储文件... >> "%LOGFILE%"
    del /f /q "C:\Windows\Minidump\*.dmp" 2>>"%LOGFILE%"
    echo [5/5] 崩溃转储清理完成 >> "%LOGFILE%"
)

echo ================================================ >> "%LOGFILE%"
echo 临时文件清理结束：%date% %time% >> "%LOGFILE%"
echo ================================================ >> "%LOGFILE%"
endlocal

这个脚本有几个细节值得说明。

rd /s /q是先删除目录及子目录，del /f /q是强制删除文件。我刻意把文件夹和文件分开处理，因为rd对非空目录会无法删除，for /d遍历目录配合rd能处理递归删除。目录遍历删除的顺序是先处理所有子目录，再处理顶层文件，这样能最大程度避免“目录非空无法删除”的失败。

2>>"%LOGFILE%"的意思是把删除过程中的错误信息（比如文件被占用、权限不足）追加到日志中，而不是让它们在屏幕上滚动。这样脚本执行时是安静模式，但事后你可以通过日志看到哪些文件删不掉。

模块三的判断逻辑值得专门说一下。sc query wuauserv | find "STOPPED"会查询Windows更新服务的状态，如果服务已停止，说明当前没有正在进行的更新操作，可以安全清理下载缓存。如果服务正在运行，则跳过，避免破坏更新进程。这个问题我在早期版本脚本里踩过坑：某个周六凌晨计划任务启动时，恰逢Windows正在后台安装更新，脚本把下载目录清空了，更新直接失败，随后系统一直提示“无法完成更新，正在还原更改”，折腾了很久才恢复。

3.3 首轮实测遇到的两个问题

第一次写完脚本，我在自己的主力机上跑了一遍，立刻遇到两个问题。

第一个是权限问题。用户临时目录下有些文件被当前账户之外的系统进程占用，del命令会报“拒绝访问”。起初我担心这些报错会污染日志，后来发现2>>重定向把错误信息全收进了日志，并不会影响其他文件的删除，也就放心了。真正需要解决的是C:\Windows\Temp目录下的部分文件——即便以管理员身份运行，也可能会因为TrustedInstaller权限无法删除。解决方法是不要动这些文件，直接跳过。Windows核心进程的临时文件通常都在使用中，留着对空间占用影响也不大。

第二个是脚本执行时间。第一次全量清理时，因为临时文件实在太多，脚本跑了将近20分钟。之后每次运行基本在2～3分钟内完成。这提醒我，第一次跑脚本时最好放在空闲时段，别让它在你正忙着处理重要事务时突然跑起来。

4. 计划任务与触发机制：让清理在后台自动运转

脚本写好了，接下来就是让它“无人值守”地跑起来。Windows 11下有两种主流方式：任务计划程序图形界面，以及schtasks命令行。两种方式各有适用场景。

4.1 创建计划任务的两种方式

图形界面操作相对直观，适合新手。在“计算机管理”里打开“任务计划程序”，点击“创建基本任务”，按要求填写名称和描述（比如“WeeklyTempClean”），触发时间设为“每周”，选择周日凌晨3点，执行程序时选择脚本路径。注意，“复选框‘使用最高权限运行’必须勾选”，否则脚本无法清理系统临时目录。

命令行方式更高效，适合需要批量部署到多台机器的情况。我用的是以下命令：

bash复制schtasks /create /tn "WeeklyTempClean" /tr "C:\Scripts\CleanTemp.bat" /sc weekly /d SUN /st 03:00 /ru SYSTEM /rl HIGHEST /f

逐项解释：/tn指定任务名称，/tr指定要执行的脚本路径，/sc weekly /d SUN表示每周日执行，/st 03:00是凌晨三点，/ru SYSTEM表示以SYSTEM账户运行，/rl HIGHEST是最高权限级别。/f表示如果任务已存在则强制覆盖。

为什么要用SYSTEM账户而不是管理员账户？因为管理员账户有可能被修改密码、登录状态变化影响，SYSTEM账户是系统级账户，始终可用，权限比管理员还高，执行清理任务不会有登录态的问题。

4.2 触发器怎么设最合理

触发时间的选择直接影响清理效果。我实测后的建议是：

凌晨3点到4点之间是黄金时段。这个时间段大多数用户已经停止工作，系统负载低，临时文件被占用的概率也相对较小。但要注意，如果你的机器设了“睡眠”模式，凌晨3点机器可能已经睡死，计划任务不会执行。

解决方案是，在创建任务时打开“条件”选项卡，勾选“只有在计算机使用交流电源时才启动此任务”，以及“唤醒计算机以运行此任务”。勾选唤醒后，即使机器在计划时间处于睡眠状态，也会被系统自动唤醒执行脚本，执行完再回到睡眠。这个机制在Windows 11 24H2上工作得很稳定。

另外，建议给任务加上“如果任务失败，每隔5分钟重新启动一次，最多重试3次”的配置，以防系统在计划时间正忙时导致脚本执行中断。

4.3 任务跑完怎么验证

创建好计划任务后，不要干等下一周。右击任务，选择“运行”，让脚本立即执行一遍，然后检查日志文件是否生成、体积是否合理。

日志文件的位置是C:\TempCleanLog目录下以日期命名的.log文件。我每次跑完脚本都会瞄一眼日志的末尾几行，确认“清理完成”字样出现，再浏览一下是否有大量的“拒绝访问”错误。如果刷出几百行“拒绝访问”，可能是脚本权限或服务状态问题，需要排查。

如果你的机器上有多个Windows账户，日志会记录每次清理的详细动作。我一般保留最近30天的日志，配合下面的空间预警脚本一起用，这样每一周C盘空间变化、清理释放了多少空间、哪些文件删不掉，都能追溯。

5. 空间预警与日志留痕：补上最后一块拼图

清理脚本加计划任务，已经能实现“每周自动清理临时文件”，但我觉得这套系统还缺一环：主动预警。清理只是为了腾出空间，但你没做监控的话，可能跑了一个月都没发现某个目录里又堆了几十GB的缓存。于是我又加了一个PowerShell脚本，用于检查C盘剩余空间，并在低于预设阈值时给出提示。

5.1 磁盘余量检查与桌面提醒

以下脚本保存为CheckDiskSpace.ps1，建议同样挂到计划任务中，每天早上9点运行一次：

powershell复制$thresholdGB = 20
$drive = Get-PSDrive C
$freeGB = [math]::Round($drive.Free / 1GB, 2)

if ($freeGB -lt $thresholdGB) {
    $message = "C盘剩余空间仅 $freeGB GB，建议立即运行手工清理或检查是否有异常大文件。"
    Add-Type -AssemblyName System.Windows.Forms
    [System.Windows.Forms.MessageBox]::Show($message, "磁盘空间预警", "OK", "Warning")
    Write-Output "$(Get-Date) - 预警触发，剩余空间: $freeGB GB" | Out-File -FilePath C:\TempCleanLog\SpaceWarning.log -Append
} else {
    Write-Output "$(Get-Date) - 空间正常，剩余空间: $freeGB GB" | Out-File -FilePath C:\TempCleanLog\SpaceCheck.log -Append
}

$thresholdGB这个阈值可以根据自己的使用习惯调整。我的主力机装了一堆开发工具和虚拟机，C盘给到256GB，20GB对我来说是告警线；如果你的C盘只有128GB，建议把阈值调到15GB。低于阈值时，脚本会弹出桌面消息框，同时把预警记录写入日志。

这里有个小坑：PowerShell执行策略默认是受限的，直接双击运行.ps1脚本会报“禁止运行脚本”。你需要在管理员PowerShell里执行一次Set-ExecutionPolicy RemoteSigned，或者在计划任务中直接调用powershell.exe -ExecutionPolicy Bypass -File "C:\Scripts\CheckDiskSpace.ps1"。我推荐后者，因为改全局执行策略可能会影响系统的其他安全策略。

5.2 日志文件怎么用

日志不能只写不读。我个人的习惯是，每个月月初打开C:\TempCleanLog目录看一眼。重点关注两种日志：

• 清理日志CleanTemp_日期.log：看清理结束时间，估算脚本耗时，确认有没有出现大面积删除失败。
• 空间预警日志SpaceWarning.log：如果这个文件内容在增长，说明C盘空间一直处于紧张状态，光清理临时文件已经不够用了，你需要检查是不是有软件把数据默认存到了C盘。

顺便说一个热搜里经常出现的问题：ComfyUI会在C盘产生临时文件吗？答案是会的，而且量不小。ComfyUI默认将模型缓存、临时节点输出存放在C:\Users\用户名\AppData\Local\Temp或ComfyUI工作目录的temp子目录下。如果你经常做AI绘画，这部分缓存是临时文件清理的重点对象。我的方案里已经覆盖了用户临时目录，所以跑一遍脚本能清掉不少残留。

5.3 把清理联动进自动化部署流程的注意事项

最近很多人用Jenkins、自动化测试平台做CI/CD部署，也问过我怎么把临时文件清理纳入自动化链路。我的建议是：可以联动，但要把清理逻辑放在“部署前”而不是“部署后”。

为什么？因为C盘空间不足会直接导致编译失败、测试环境启动失败。在一套Windows测试机上，如果每次都因为临时文件堆积导致构建任务失败，可以在Jenkins任务的“构建前执行”步骤里加入调用清理脚本的命令，确保每个构建任务开始时都有一个干净的环境。

但要特别注意：构建机器和工作站不同，构建目录、依赖缓存、测试报告既不能乱清理，也不能放在%TEMP%下。在CI/CD环境中，我一般把清理脚本的“排除清单”做得更严格——只清理用户临时目录和Windows更新缓存，不碰任何可能与构建产出物有关的路径。否则，你清理的可能是构建系统正在使用的依赖库，轻则构建失败，重则环境损坏。

6. 从临时文件到全局空间管理的经验沉淀

整套系统运行了一段时间后，我最大的体会是：清理临时文件这件事，本身不算高深，但把它真正做到“全链路自动化”，关键不在于脚本写得多花哨，而在于你是否真正理解了自己的系统里什么文件会被反复生成、什么文件必须保留、什么情况会干扰清理过程。

举一个具体的例子。我在开发机上同时装了两套大型工具链，一套用于嵌入式编译，一套用于前端构建。嵌入式编译工具会在%TEMP%下生成大量预处理文件，每次编译都会产生几百MB的中间产物；而前端构建工具的依赖缓存放在了%APPDATA%\npm-cache。我的脚本一开始只清理%TEMP%，发现空间释放效果不明显，后来在前端构建工具的配置里把缓存目录改到了D:\npm-cache，才算彻底解决了开发机C盘频繁告警的问题。这让我意识到，清理脚本能解决的是“系统里已经堆积的垃圾”，但真正好的空间管理，还要配合“从源头减少垃圾产生”的手段。

另外，Windows 11版本迭代很快，不同版本的系统对临时文件的管理策略会有差异。比如24H2之后，“存储感知”功能强化了自动清理能力，系统会默认定期清理DeliveryOptimization下的缓存。如果系统版本较新，你的清理脚本里有些模块可能会“无所事事”，这是正常的，保留它们作为兜底即可。

在写这套方案的过程中，我最后还是决定把脚本和日志目录放在系统盘之外（比如D盘或OneDrive同步目录）。这样即使系统重装，清理脚本和历年清理日志都能保留，后续排查空间问题时也能快速找到历史依据。这是我踩过重装系统后脚本丢失、日志全无的坑之后换来的经验。

最终，这套系统从手动清理到自动化，再到空间预警，整个链路并不需要装什么第三方软件，纯靠Windows自带的批处理、PowerShell和计划任务就能完成。如果你也被C盘反复标红折磨，不妨先按本文介绍的方案搭一套自己的清理流水线，跑一个月再回头看，你会明显感觉到“临时文件焦虑”在下降。