企业官网建设流程全解析

“智能管理临时文件”这个话题，说穿了就是处理“磁盘被塞满、系统越来越慢”的日常救火问题。做了几年开发，几乎每台机器都会染上这个病：不管初始硬盘多大，用上一段时间后，剩余空间总会莫名其妙缩水。有一次一个写模拟项目X的开发机只剩几个GB，排了好久才发现是某软件的历史安装包、多版本缓存和日志文件堆出来的，动辄几十个GB。手动清理只能爽一天，第二天临时文件又悄悄长回来。

所以最合适的做法不是隔几个月清一次，而是把它做成定时、自动、只删“该删的”、保留“该留的”自动化任务。下面我会从方案设计到跨平台代码逐层拆解，给出的脚本基本可以直接拿去生产环境跑，只要你先用干跑模式验证一遍。这篇内容适合个人电脑用户、开发者的工作机，也适合小团队服务器的系统管理员；内容很长，但每个环节都能直接落地。

1. 为什么需要临时文件自动化管理

1.1 临时文件从哪里来，又“悄悄”塞满了谁的硬盘

临时文件不是某一种单一文件，而是操作系统、应用软件和日常操作产生的过程性残留。拆开看，至少有这么几类：

• 系统与软件更新产生的安装包、补丁缓存。软件升级时通常会先把新版本解压到临时目录，正常结束后应自行清理，但很多程序更新完就忘了这片区域，一次升级可能留下几百MB，几个月下来就是几十GB。
• 编辑器、办公软件和建模工具的自动备份与临时工程文件。崩溃恢复确实有用，但恢复完成后不会自己把你抢救出来的临时副本删掉。
• 压缩包解压过程中的中间目录。你顺手解压一个大型资源包，卡到一半或中途取消，那些半成品文件就留在临时目录里。
• 浏览器下载产生的中转文件。已经是下载完毕了，但某些浏览器会在临时缓存路径里保存一份，导致你在下载目录里看到一遍，缓存目录里还躺着一遍。
• 各类程序的运行日志。日志单个文件不大，但按天切割、按份追加，长期不治理也会涨到几个GB。
• 开发工具链的构建缓存。构建工具会把中间产品、本地仓库缓存、历史版本全放在本地临时目录里，这类通常最占空间，动不动就是几十GB。

我在多台机器上实测得到的典型数字：一台Windows本机的C:\Windows\Temp加用户AppData\Local\Temp能到12GB以上，一大半是没删干净的更新包；一台Linux工作站的/tmp加~/.cache合计能到30GB；单纯把日志目录里的旧文件列出来，也有几百MB到2GB。

1.2 不管它的代价不只是磁盘剩余空间这一件事

很多人的第一反应是“反正我硬盘够大，让它占着呗”。但等到你真正踩过一次坑，就会意识到代价远不止“少几个GB可用空间”这么简单。

首先是磁盘满后的连锁反应。临时文件把磁盘占满后，程序写日志会失败、缓存写回会报错、数据库的临时文件可能直接导致事务中断。更隐蔽的是，这类问题往往发生在凌晨定时任务或者高负载处理时段，排查起来非常难受。

其次是系统性能的钝化。文件系统在存储海量小文件时，目录条目会变得很庞大。杀毒软件扫描、文件索引、备份工具遍历时，都会把时间消耗在“数不清的细碎文件”上。同一个操作在干净目录里可能只要几毫秒，在塞满几十万个小文件的目录里就要卡几秒甚至更久。

第三是备份成本的虚高。备份软件默认会把临时目录一并处理，导致备份体积膨胀、耗时变长。如果你的备份目标是外置盘或云端存储，多出来的临时文件还会直接折算成时间成本和存储成本。

第四是数据和隐私风险。日志、会话缓存、自动保存的临时副本，里面很可能带着你的文档片段、账号会话信息甚至内部业务数据。一旦终端设备丢失，或目录权限配置不当，这些残留可能比正常文档更容易被翻出来。

1.3 手动清理为什么永远追不上临时文件的再生速度

也有人很勤快，隔一段时间就去系统设置里点“临时文件”清理。那我直说：这条路解决不彻底，而且会让你误以为“已经清理过了”。

手动清理的问题很典型。一是靠记忆，你不可能每次都记得清干净所有位置；二是系统自带的清理工具只认它自己列表里的目录，第三方软件的缓存它管不着；三是很多文件被占用着，你以为删干净了，其实只删掉了能删的那一部分，剩余的还是原样躺着。更危险的是，手动清理时容易图省事把整个目录选中，误删了某些服务还在读取的配置或会话文件，这种错误比磁盘满更致命。

真正要命的是再生速度。你费劲清出20GB，过两周一看又回去了。临时文件本质上是程序运行过程中的“排泄物”，只要机器还在跑，它就在持续产生。既然无法禁绝产生，唯一理性的策略就是把“清理”这件事本身变成自动化、高频、可复盘的任务。

2. 自动化清理方案的整体设计

2.1 一个可落地的清理任务，必须包含四个要素

我在设计清理方案前，先把它拆成四个核心要素，缺一个都会出问题。

清理范围。不是“所有临时文件”，而是精确到目录列表。例如 Linux 下的/tmp、/var/tmp，用户主目录下的~/.cache、~/.local/share/Trash；Windows 下的%TEMP%、C:\Windows\Temp、用户AppData\Local\Temp。范围写清楚后，脚本永远只在这些路径内操作，不会越界。

保留策略。必须回答“什么样的文件可以删”。最常用的是按最后修改时间判定：修改时间超过 N 天的文件才删。比如/tmp里超过 3 天的可以删，~/.cache里超过 7 天的可删除，日志文件超过 30 天的可清理。按照时间窗口而不是按文件类型判定，会更安全，因为一个正在使用的临时文件通常会被频繁读写，最后修改时间不会太旧。

运行频率。低频任务（每周跑一次）适合做被动防守，高频任务（每小时跑一次）适合做主动清理。我建议根据磁盘紧张程度来选：开发机一周一次，服务器一天一次，CI构建机可以每小时一次。频率太高会浪费系统资源，频率太低则达不到效果。

安全机制。这一条放在最后，但重要性最高。包括白名单、黑名单、干跑模式、日志审计、灰度上线。白名单是“绝对不能清空的目录”，黑名单是“即使是临时文件也不能碰的文件和后缀”，干跑模式是先打印“会删什么”而不是真删，日志则是每次清理动作都有据可查。

2.2 技术选型：脚本、调度器与平台

技术选型的原则是“用最简单、最稳定、最少依赖的方式覆盖你要管的机器”。

Linux 和 macOS 上，我优先选 Bash 脚本加 cron 或 systemd timer。Bash 内置了文件遍历、删除、日志重定向的能力，find命令做时间过滤非常成熟，不需要额外安装任何东西。调度上，传统 cron 足够处理绝大多数场景；如果你管理的机器支持 systemd，用 timer 更好，因为可以绑定在系统启动完成后运行，日志通过 journald 统一管理。

Windows 上，我选 PowerShell 加任务计划程序。PowerShell 原生支持对目录递归遍历、删除、捕获错误，配合-WhatIf参数能很好实现干跑模式。任务计划程序可以设置触发器、指定用户权限、配置“运行任务时达到的最高权限”，这些正好满足清理任务的需求。

为什么不推荐用图形化清理工具？图形工具适合单台机器的一次性清理，不适合规模化部署，也没法做到“每周自动跑、日志自动存”。对于多台机器或服务器场景，脚本才是可版本化、可审计、可灰度发布的方案。Python 也可以作为备选，当清理逻辑复杂到需要解析白名单配置、需要处理大量规则时再用它，大多数情况下 Bash 和 PowerShell 已经足够。

2.3 我定下的设计原则：先干跑、再正式执行

无论脚本写得多完美，我都不建议第一天就让它“真删”。设计上采用灰度递进：

• 第一阶段：只打印报告。脚本统计出各目录的占用、待删除文件数量和空间，写入日志但不删除。
• 第二阶段：只删“绝对能确认安全”的文件。比如限定文件后缀为.tmp、.log、.cache，且最后修改时间超过一个很长的安全期（比如 30 天）。
• 第三阶段：逐步放宽时间阈值和后缀范围，同时每天检查日志，确认没有误删反馈。

另外，脚本必须保证幂等。怎么解释幂等？就是同一份脚本跑两次、三次，结果都应该一样，不会有副作用。具体到清理任务，脚本运行结束不能给系统留下下一轮运行需要处理的“半完成状态”，干跑和正式删除之间的差异，也必须做在参数切换上而不是在脚本逻辑里。

删除前一定要先看“将要删除什么”。这也是为什么所有样例脚本我都强制包含DRY_RUN参数，默认值为 1，不显式改成 0 就永远只打印不删除。

提示：生产服务器上第一次跑清理脚本，务必用干跑模式连续观察至少三天。观察的不只是待删除文件列表，还有脚本本身有没有异常报错、有没有扫到预想之外的大目录。

3. Linux/macOS 落地：Bash脚本加 cron 的自动化清理实现

3.1 只删“够老”的文件：find 的 mtime 和 maxdepth 控制

Linux 和 macOS 上，find命令是清理任务的绝对主力。核心用法是：

find /tmp -type f -mtime +3 -delete

这个命令的意思是：在/tmp目录下找普通文件（-type f），最后修改时间超过 3 天的（-mtime +3），然后删除（-delete）。-delete选项如果放在最后，会直接执行删除；如果不加，find只会打印符合条件的文件路径。

工欲善其事必先利其器，有几个参数我建议严格执行：

• -maxdepth 1或指定的深度。临时目录下经常套着层级很深的子目录，比如/tmp/someapp/xxx/yyy。如果全部递归，可能误删某个程序正在使用的深层目录。按场景设定深度，例如只清理/tmp第一层，或者只清理特定应用的专属目录。
• -type f只删普通文件，不碰目录本身。目录条目留给系统自己处理，避免删除目录导致程序找不到目录而重建异常。
• -mtime +N用最后修改时间做过滤。为什么不用创建时间？在很多文件系统上，创建时间并不稳定，迁移文件后可能变化，最后修改时间则最能反映“这个文件是否还在被使用”。正在使用的临时文件通常会被持续更新，-mtime +7就能把它们筛掉。
• -files0-from配合统计可以处理“大批文件删除”的场景。当文件数量多到命令行参数装不下时，find配合-print0加xargs -0是更稳的方式。

3.2 一份可以直接抄的 Bash 清理脚本

下面这份脚本我实际在开发机和服务器上跑过，按需改目录列表和时间阈值即可。它支持干跑模式，并默认把日志追加到固定位置。

#!/usr/bin/env bash set -euo pipefail # 可配置区域 TARGET_DIRS=( "/tmp" "/var/tmp" "${HOME}/.cache" "${HOME}/.local/share/Trash" ) TMP_DAYS=3 CACHE_DAYS=7 LOG_DAYS=30 # 日志目录 LOG_DIR="${HOME}/.local/state/tmp-cleaner" mkdir -p "${LOG_DIR}" LOG_FILE="${LOG_DIR}/clean-$(date +%Y%m%d).log" # 干跑模式：DRY_RUN=1 只打印不删除 DRY_RUN="${DRY_RUN:-1}" log_info() { echo "$(date '+%Y-%m-%d %H:%M:%S') [INFO] $*" | tee -a "${LOG_FILE}" } clean_dir() { local dir="$1" local days="$2" if [ ! -d "$dir" ]; then log_info "目录不存在，跳过: $dir" return 0 fi log_info "扫描: $dir (超过${days}天)" if [ "${DRY_RUN}" == "1" ]; then # 干跑：统计符合条件文件的总大小和数量 local file_count local total_size file_count=$(find "$dir" -type f -mtime "+${days}" 2>/dev/null | wc -l) total_size=$(find "$dir" -type f -mtime "+${days}" -print0 2>/dev/null | \ xargs -0 du -cb 2>/dev/null | tail -n 1 | cut -f1) log_info " [干跑] 待删除文件数: ${file_count}, 总大小: ${total_size:-0} 字节" else # 正式执行：删除前先打印数量，然后逐条删除 local before_count before_count=$(find "$dir" -type f -mtime "+${days}" 2>/dev/null | wc -l) find "$dir" -type f -mtime "+${days}" -delete 2>>"${LOG_FILE}" log_info " [执行] 本次删除文件数: ${before_count}" fi } for dir in "${TARGET_DIRS[@]}"; do case "$dir" in "/tmp"|"/var/tmp") clean_dir "$dir" "${TMP_DAYS}" ;; *".cache"*) clean_dir "$dir" "${CACHE_DAYS}" ;; *"/Trash"*) clean_dir "$dir" "${LOG_DAYS}" ;; *) clean_dir "$dir" "${CACHE_DAYS}" ;; esac done log_info "清理任务结束，退出码 $?"

脚本最核心的几处细节：

• set -euo pipefail保证脚本在管道出错或变量未定义时能及时终止，不会在坏状态下继续删除。
• 干跑模式不会真正执行删除，只会统计“多大、多少”并打印路径样例。
• 正式执行时，find ... -delete 2>>"${LOG_FILE}"把删除失败的错误追加到日志，并不中断整个任务。某个文件被占用删不掉，脚本会继续处理后面的文件。

3.3 用 cron 和 systemd timer 把脚本变成自动化任务

把脚本放到固定位置，例如/usr/local/bin/clean-tmp.sh，然后执行chmod +x /usr/local/bin/clean-tmp.sh给它执行权限。

传统 cron 的注册方式：

crontab -e

在里面追加一行：

0 3 * * 1 /usr/local/bin/clean-tmp.sh >> ~/.local/state/tmp-cleaner/cron.log 2>&1

这行的含义是：每周一凌晨 3 点执行一次清理脚本，标准输出和错误输出都追加到日志文件。选择凌晨跑是因为这个时段系统负载最低，且很多定期任务已结束。

如果你用的系统支持 systemd，我更推荐用 timer 来跑，因为 cron 对系统休眠状态和随机延时的处理比较生硬。创建两个文件：

/etc/systemd/system/tmp-cleaner.service内容：

[Unit] Description=Temp files weekly cleaner After=network.target [Service] Type=oneshot ExecStart=/usr/local/bin/clean-tmp.sh

/etc/systemd/system/tmp-cleaner.timer内容：

[Timer] OnCalendar=Mon *-*-* 03:00:00 RandomizedDelaySec=300 Persistent=true [Install] WantedBy=timers.target

然后执行：

systemctl daemon-reload systemctl enable --now tmp-cleaner.timer

RandomizedDelaySec=300让任务在 3 点后的 5 分钟内随机启动，避免大规模部署时所有机器同时清理造成 IO 尖峰；Persistent=true则保证如果机器在计划时间处于关机状态，下次开机后会自动补跑一次，这个特性恰好解决临时文件清理容易漏跑的问题。

注意：cron 环境里的PATH和交互式终端下不一样。脚本里调用find、xargs、du等命令时，最好使用绝对路径，或者在脚本开头显式设置export PATH="/usr/bin:/bin:/usr/sbin:/sbin"。我在实践里见过太多次 cron 任务静默失败，原因就是find找不到命令。

4. Windows 落地：PowerShell脚本加任务计划程序的自动化清理实现

4.1 PowerShell 清理脚本：从回收站到临时目录

Windows 上，清理临时文件最自然的方式是写一个 PowerShell 脚本。它可以直接访问$env:TEMP、$env:LOCALAPPDATA这些环境变量，也可以从一个 CSV 或数组里读取目标目录列表。

下面这是我在 Windows 开发机上使用的简化版脚本，保留干跑模式，和 Linux 版本同一个思路。

param( [switch]$DryRun = $true ) $ErrorActionPreference = "Continue" $LogDir = Join-Path $env:LOCALAPPDATA "TmpCleaner" if (-not (Test-Path $LogDir)) { New-Item -ItemType Directory -Path $LogDir | Out-Null } $LogFile = Join-Path $LogDir ("clean-{0:yyyyMMdd}.log" -f (Get-Date)) $TargetDirs = @( (Join-Path $env:TEMP "*"), "C:\Windows\Temp\*", (Join-Path $env:LOCALAPPDATA "Microsoft\Windows\INetCache\*"), (Join-Path $env:LOCALAPPDATA "CrashDumps\*"), (Join-Path $env:LOCALAPPDATA "Temp\*") ) $Days = 7 $Threshold = (Get-Date).AddDays(-$Days) function Write-Log { param([string]$Message) $line = "{0} [INFO] {1}" -f (Get-Date -Format "yyyy-MM-dd HH:mm:ss"), $Message $line | Tee-Object -FilePath $LogFile -Append } foreach ($pattern in $TargetDirs) { $files = @(Get-ChildItem -Path $pattern -Recurse -File -Force -ErrorAction SilentlyContinue | Where-Object { $_.LastWriteTime -lt $Threshold }) if ($files.Count -eq 0) { Write-Log "扫描 $pattern 无超期文件" continue } $totalSize = ($files | Measure-Object -Property Length -Sum).Sum Write-Log "扫描 $pattern : 文件数 $($files.Count), 总大小 $([math]::Round($totalSize/1MB,2)) MB" if (-not $DryRun) { $deleted = 0 foreach ($f in $files) { try { Remove-Item -LiteralPath $f.FullName -Force -ErrorAction Stop $deleted++ } catch { Write-Log "删除失败: $($f.FullName) -> $($_.Exception.Message)" } } Write-Log "本次删除 $deleted 个文件" } else { Write-Log "[干跑] 会删除 $($files.Count) 个文件" } } Write-Log "清理任务结束"

这段脚本有几个重要的设计决策：

• $ErrorActionPreference = "Continue"让脚本在遇到无权限文件时继续执行，而不是中断。实际清理临时文件时，总有文件被系统或进程占用，一次失败就中断会导致后面的目录完全清不到。
• -LiteralPath用于删除，避免文件路径里包含方括号等特殊字符时被当成通配符处理。这一点很多 Windows 清理脚本都会踩坑。
• 删除前不清空目录，只按“文件最后修改时间超过阈值”逐个清理，比整目录删除安全得多。因为C:\Windows\Temp下某些正在使用的文件，时间戳通常都是最新的。

4.2 用任务计划程序注册一个计划任务

把脚本保存为D:\Scripts\clean-tmp.ps1，然后就可以把它注册到任务计划程序。

如果更习惯图形界面，操作路径是：开始菜单搜索“任务计划程序”，创建基本任务，触发器选“每周”，指定周日凌晨 3 点，操作选“启动程序”，程序填powershell.exe，参数填-ExecutionPolicy Bypass -File D:\Scripts\clean-tmp.ps1。

命令行注册方式更利于批量复制：

schtasks /create /tn "TmpCleaner" ^ /tr "powershell -ExecutionPolicy Bypass -WindowStyle Hidden -File D:\Scripts\clean-tmp.ps1" ^ /sc weekly /d SUN /st 03:00 ^ /ru SYSTEM /rl HIGHEST /f

注册完成后，可以先手动运行一次确认脚本能正确输出日志：

schtasks /run /tn "TmpCleaner"

检查最近一次运行结果：

schtasks /query /tn "TmpCleaner" /v /fo LIST

4.3 关于权限、占用与策略设置的经验补充

Windows 清理脚本最麻烦的地方在于权限模型。同一个文件，你的登录用户没有权限删除，换成 SYSTEM 用户可能就可以了。所以在任务计划程序里我用/ru SYSTEM，以系统最高权限运行，能最大程度扫掉C:\Windows\Temp里需要管理员权限才能删的更新残留。

但高权限也意味着高风险。脚本里的目标路径必须收敛，绝不能出现C:\*这种泛化范围。我在实际运行中发现，PowerShell 对通配符的处理比 Bash 更“激进”，一旦路径写错，它会在整个盘上匹配目标目录，那后果就是灾难性的。

PowerShell 执行策略也可能让任务计划程序运行失败。-ExecutionPolicy Bypass参数能绕过执行策略限制，但注意这只对当前进程有效，不会改变系统级策略，所以我通常就在 schtasks 命令里带上这个参数，而不是去修改系统策略。

另外，Windows 系统有些目录不应该出现在清理列表里，比如C:\Windows\SoftwareDistribution\Download是 Windows Update 的下载缓冲，直接删除会导致后续更新出问题；C:\Windows\System32\DriverStore存放驱动缓存，也不建议脚本介入。我把它们加入“绝对白名单”，脚本里通过Where-Object或-Exclude参数排除。

5. 常见问题、权限绕过与避坑笔记

5.1 文件被占用导致的“部分删除失败”

第一个跑自动化清理必然会遇到的现象：每次跑完，日志里都会有一批“删除失败”。刚看到时很慌，以为脚本有问题，后来想明白了，这是常态而不是异常。

为什么删不掉？最常见的原因是文件正被某个进程打开。程序在启动时读取了临时文件，或者写日志时没关闭句柄，Windows 和 Linux 都会拒绝删除这种文件。另一个原因是权限不足，系统关键目录下的临时文件对普通用户是只读的，不做提权操作就删不掉。

怎么处理？不要因为个别文件失败而中断整个清理任务。脚本里我用-ErrorAction Continue或2>>log记录错误后继续处理下一个文件。过几天再跑，那些之前被占用的文件大概率已经被释放，自然就清掉了。所以我把“允许部分失败”写进了设计原则，运行频率高一点，比纠结单次清理完整性更实际。

5.2 脚本没执行？先查这三件事

自动化任务最常见的坑就是“静默失败”，任务计划显示已运行，但文件一个没删。我排查时固定按三个方向查。

第一查调度环境。cron 任务里我吃过PATH的亏，脚本在终端手工执行正常，到了 cron 里就报“命令找不到”。解决方法是脚本开头强制设置PATH，或者所有外部命令都用绝对路径。Windows 任务计划程序里则要检查“起始于”目录，PowerShell 脚本依赖相对路径时，任务计划的工作路径可能和预期完全不同。

第二查权限位。Linux 上脚本如果缺少x权限，cron 会直接失败；Windows 上如果任务计划指定了高权限用户，但该用户的登录密码有变化，也可能导致任务无法运行。建议注册任务时优先使用 SYSTEM 账户或服务账户，而不是个人账户。

第三查输出日志。清理脚本必须写完整的运行日志，包括开始时间、扫描目录、删除数量、退出码。只要日志还在，80% 的问题都能通过日志定位。我见过有人在清理任务里不写日志，后来出了问题只能凭感觉猜，那是自找麻烦。

5.3 误删重要临时文件的档案例子

踩过最大的坑是“想当然地把某个目录当成临时目录”。当时在一台业务服务器上部署清理脚本，图省事把/var/tmp整个纳入了清理范围。跑了一周，日志显示删除正常，结果一位同事说某批重要的积压数据没了。那套数据处理程序把中间结果写到/var/tmp下，文件名无后缀，最后修改时间也很旧，我的脚本按“超过 30 天就删”全部清空了。

这个教训非常贵。临时目录里不只有垃圾，也可能有某些应用默认的“工作目录”和“离线缓存的业务数据”。从此我立了一条规矩：任何目录纳入自动化清理前，先问三个问题——这个目录归谁？里面的文件用途是什么？有没有可能被其他程序依赖？回答不上来的目录一律先排除。

另外，清理前必须用干跑模式观察名单。干跑日志会告诉你“它到底会删什么”，多扫几遍，确认清单里没有业务性文件，再切到正式模式。不要嫌麻烦，这个步骤能救你一命。

5.4 清理动作的安全审计与灰度上线思路

有人说“清理临时文件还要灰度？听起来太夸张了”。但如果你管理的机器超过一台，灰度上线就是必须的。

推荐的灰度落地路径：先在个人开发机上跑一周，观察日志；再把脚本同步到一台低风险的测试服务器，同样先干跑三天；确认无误后，再分批扩展到生产机器。生产机器上第一次运行时，把时间阈值设得很保守，比如平时设 7 天的，生产环境第一周设 30 天，等日志数据积累足够后再动态调小阈值。

审计方面，我坚持“每次删除动作都落日志”。日志里至少包含三列：删除的文件路径、文件大小、删除时的退出状态。这样即使后来出了状况，你也能精确知道是哪个文件在什么时候被哪次任务删掉的。日志保留我建议至少 90 天，别为了省那点磁盘又把审计日志塞进另一次清理范围。

还有一点容易被忽略：清理脚本本身也要纳入版本管理。不要只在服务器上留一份没人知道是谁写的脚本。用版本管理工具维护脚本和配置，每次修改都留下提交记录，这样出问题时还能回滚到上一个版本。我从踩坑中养成的习惯是：脚本更新后先观察两轮运行日志，再回填到其他机器。

我个人在实际操作中最深的体会是，自动清理临时文件这件事，难点从来不在“写一段删除命令”，而在于“如何知道哪些文件真的该删”。与其追求一键清出 50GB 的快感，不如花时间把目录范围、保留策略、白名单和日志审计打磨好。脚本写得越保守，跑得越久越省心。

最后再分享一个小技巧：给清理脚本加一个“安全阀”，当剩余磁盘空间低于一个阈值时自动停止删除，并把告警发到手上。这个逻辑很简单，但能防止你在磁盘满的慌乱中还误删了不该删的东西。临时文件的管理，本质上不是为了把空间清到最大，而是为了让系统在长期运行中保持稳定可预测，这一点想通了，很多方案取舍其实都顺理成章。