先说点实在话。临时文件这东西几乎每个用电脑的人都会碰到但真正把它当回事的人不多。我曾经在一台测试服务器上见过 /tmp 目录里堆了接近 30GB 的垃圾里面全是各种安装包残留、编译中间产物和半年前的日志切片。更麻烦的是这台机器磁盘已经告警了可没人敢手动删——因为谁都不确定里面有没有哪个文件正在被某个服务使用。这种场景相信不少运维和开发朋友都遇到过。临时文件自动化方案说白了就是用一套确定的规则和工具代替“人工不定期清理”这个不靠谱的习惯。它解决的是三个层面的问题磁盘空间被不知不觉吃光、临时文件混乱导致排障困难、以及手动删除时误删正在使用的文件造成事故。这篇文章适合运维工程师、开发者、以及想把自己电脑整理干净但不想天天操心的朋友。我会从方案选型、脚本设计、定时任务配置、误删防护一直讲到 CI/CD 和容器环境里的进阶玩法全程给可复现的命令和配置。1. 临时文件为什么需要一套自动化清理方案1.1 临时文件是怎么悄悄长大的临时文件不是只有一个 /tmp 目录那么简单。按照来源大致能分成几类操作系统运行时会产生的套接字文件、PID 文件、软件安装包残骸包管理器缓存比如 apt、pip、npm、yarn 留下的缓存开发工具的编译产物像 dist、build、target 目录以及 node_modules/.cache还有日志切割后的历史文件。每一类单独看都不大但架不住积少成多。我见过一个很典型的例子一个 Java 项目的编译构建每次会在 /tmp 里留下几百 MB 的中间文件。开发环境跑了几周/tmp 就被撑到了 20GB。还有个前端项目node_modules/.cache 里缓存了几百 MB 的 webpack 持久化缓存磁盘空间莫名其妙就少了。这种问题最大的迷惑性在于你根本不知道是谁写的也不知道什么时候写的排查起来特别费劲。如果是在 Linux 服务器上inode 耗尽比磁盘满更隐蔽。一个目录里塞了上百万个小文件df -h 看着还有空间但 df -i 已经 100% 了这时候任何新文件都创建不了系统行为变得非常诡异。这类问题一旦发生手动清理难度极大没有自动化方案几乎只能靠重建文件系统来恢复。1.2 手动清理的三个硬伤手动清理临时文件看起来简单实际做起来有三个绕不过去的硬伤。第一个是频率问题。人一定会忘记。磁盘告警才想起来去清理往往已经是火烧眉毛的时刻。我见过很多人平时不关心等到发现磁盘满了才临时抱佛脚地删文件删完过两个星期又满了陷入无限循环。第二个是判断问题。哪些临时文件可以删、哪些不能删需要根据文件的修改时间、访问时间、当前是否被进程占用来判断。手动操作时没人愿意逐项分析结果要么一刀切乱删要么干脆一个都不敢动。第三个是路径问题。临时文件分布在系统的各个角落从 /tmp、/var/tmp 到用户目录下的 .cache、项目目录里的构建产物甚至容器运行时的 overlay 层。手动清理很难覆盖全而且每次执行的操作命令可能都不一样最终效果完全不可控。1.3 自动化方案解决的核心问题自动化清理最大的价值不是“替你点了删除按钮”而是把清理这回事从“随机事件”变成“确定性行为”。确定性的含义包括定期执行、规则明确、操作可审计、结果可追踪。规则明确指的是你可以精确指定哪些目录、按什么条件、删除多老的文件。比如“删除 /tmp 下超过 7 天没修改过的文件”这是一条可执行、可验证的规则。操作可审计指的是每次执行都留下日志删了多少文件、释放了多少空间都记录在案出问题能回溯。结果可追踪则意味着你能通过日志和告警知道清理动作是否成功、是否有异常。一旦这套东西搭建起来它就能自己运转不再依赖人工的临场判断。我自己的习惯是“先盘家底、再定规则、后上自动化”下面几个章节就是围绕这个思路展开的。2. 方案选型从“能用”到“好用”2.1 系统自带方案不用白不用如果只看 Linux 系统本身其实已经内置了几套基础的临时文件管理机制其中最值得了解的是 systemd-tmpfiles 和 tmpreaper。systemd-tmpfiles 通过配置文件来声明哪些目录要清理、按什么规则清理。配置文件放在 /etc/tmpfiles.d/ 下语法很直白。举个例子# /etc/tmpfiles.d/clean-tmp.conf d /tmp 1777 root root 7d D /var/tmp 1777 root root 30d第一行表示 /tmp 目录保留 7 天超过这个期限的文件会被 systemd-tmpfiles --clean 处理。第二行的 D 表示目录本身和里面的内容一起清理保留周期 30 天。这个方案的好处是零额外依赖、声明式管理适合规则不复杂的场景。tmpreaper 则是传统 tmpwatch 的增强版用起来更灵活。比如这条命令tmpreaper 7d /tmp含义是删除 /tmp 下 7 天未访问的文件。tmpreaper 的优势在于它考虑了很多边界情况比如不会去动正在被进程使用的文件、知道怎么处理符号链接、还支持排除规则。不过在不少现代 Linux 发行版里systemd 已经成为默认 init 系统systemd-tmpfiles 明显是更“原汁原味”的选择。还有一个很实用的系统机制是 logrotate。它管理的是日志文件不是普通临时文件但日志和临时文件经常混在一起。给日志配置好按大小或日期切割再配合 rotate 份数限制能从源头上避免日志文件无限增长。很多生产事故其实就是日志把磁盘写满了。这两类系统方案的共同问题是“够用但不够细”。如果只有几条静态规则那直接用 systemd-tmpfiles 就够了如果你需要按目录、按条件、按项目自定义复杂的清理逻辑就得用脚本。2.2 脚本方案最灵活也最危险脚本方案的核心就是两个工具find 负责查找cron 或 systemd timer 负责定时执行。它灵活在哪里你可以自由组合路径、时间条件、文件类型、大小条件还可以在删除前做任何你想做的预处理。但是脚本方案也是最危险的。原因在于find 命令是一个纯粹的“执行者”它不会理解文件是否重要。一条命令写错可能把不该删的全删了。比如很多人刚接触时会写 find / -name *.log -exec rm {} ;这行命令会去系统里找所有 .log 文件然后删掉包括某些应用正在写入的日志后果不堪设想。因此脚本方案的准入门槛是你必须严格遵守“先 dry-run、再真实执行”的原则。dry-run 就是只打印会删除哪些文件不真正执行删除。这一步能帮你提前发现规则写错的问题。下面这行命令就是 dry-run 的典型写法find /tmp -type f -mtime 7 -print先看输出确认列出来的文件全是该清的再把 -print 换成 -delete或者接上 -exec rm 来真正执行。2.3 工具链方案处理特定生态的残留系统方案和脚本方案解决的是通用临时文件。但在真实场景里最有价值的是针对特定生态做清理。我举例说明几类项目构建产物。node 项目里的 node_modules/.cache、dist、buildJava 项目里的 targetPython 项目里的pycache。这些目录量大、增长快而且重建成本低。清理它们通常不用犹豫。可以写一个项目级清理脚本当项目不再活跃时自动清掉这些构建缓存。包管理器缓存。pip 的 ~/.cache/pipnpm 的 ~/.npmapt 的 /var/cache/apt。这些缓存删掉之后下次安装包会重新下载但在磁盘紧张的时候它们是最好的“出血点”。我通常在 CI 镜像构建的最后阶段清掉这些缓存能显著减小镜像体积。Docker 相关的残留。docker system prune -f 能清理悬空镜像和停止的容器/var/lib/docker/overlay2 里堆积的层文件是磁盘大户。配合日志轮转和镜像保留策略能避免 Docker 占据大量磁盘。每种生态都有自己的一套清理规则脚本的灵活性在这里体现得淋漓尽致。但要注意工具链方案往往涉及特定业务逻辑最好能结合项目实际情况做保留策略而不是一刀切全删。2.4 选型建议与对比我直接给一个决策表格方便你对号入座方案优势劣势适用场景systemd-tmpfiles零依赖、声明式、系统原生规则表达能力有限常规 /tmp 和 /var/tmp 清理tmpreaper安全边界处理较好、主动检查占用部分发行版需额外安装传统服务器、复杂排除规则自写脚本 cron/timer完全可控、可定制业务逻辑风险高依赖编写者水平多目录、混合规则的项目环境docker system prune专攻容器残留、集成度高只处理 Docker 生态CI 跑机、容器化部署环境商业/平台级工具集中管理、告警完善引入成本高多机、多团队的大规模治理选型的核心原则是盘子里有多少菜决定你用多大锅。单机服务器上几条规则别一上来就上重量级平台方案而真正的大规模集群环境光靠几个 cron 脚本也撑不住这时候才需要集中管理和统一的度量体系。3. 实操搭一套最小可用的自动清理系统这一节我会完整走一遍实际搭建流程从盘家底、写规则到挂定时任务全部是可复现的命令和配置。我先说明一下我的环境假设一台 Ubuntu 22.04 服务器Docker 和 Node 环境都有目标是每天自动清理各类临时文件。3.1 第一步盘点目录和设计保留策略在动任何命令之前先花半小时做一次“家底盘点”。你需要明确知道这台机器上哪些目录是真正需要清理的以及每个目录的合理保留周期。我推荐的盘点方法是先全盘扫一遍目录占用定位最大的几个目录du -h --max-depth1 /tmp 2/dev/null | sort -hr | head -20 du -h --max-depth1 /var/tmp 2/dev/null | sort -hr | head -20 du -h --max-depth2 ~/.cache 2/dev/null | sort -hr | head -20然后根据目录实际内容和业务要求给每个目录设定保留周期。我给一套通用的初始策略你可以直接抄目录保留周期说明/tmp1~3 天系统临时文件生命周期极短/var/tmp7~30 天相对持久但也不应长期堆积~/.cache/pip、~/.npm30 天重新下载成本低但没必要天天删项目 target、dist、node_modules/.cache7 天构建产物可重建日志切割后的旧文件7~14 天由 logrotate 管理更佳Docker 悬空镜像立即清理docker system prune 处理注意保留周期的设定不是拍脑袋。太短可能导致正在使用的文件被删太长则清理没意义。我的经验是“宁保守勿激进”初次设定可以给到双倍周期运行一两周观察后再逐步缩短。3.2 第二步写核心清理脚本脚本是整套系统的核心。我给出一个我实际在用的版本做了精简但核心逻辑完整。它支持日志输出、支持排除规则、也支持 dry-run 模式。#!/usr/bin/env bash # 临时文件自动清理脚本 # 用法: # ./clean-tmp.sh --dry-run # 只打印将删除的文件不实际删除 # ./clean-tmp.sh # 真实执行清理 set -euo pipefail DRY_RUNfalse if [[ ${1:-} --dry-run ]]; then DRY_RUNtrue fi LOG_FILE/var/log/clean-tmp.log # 需要清理的目录列表空格分隔 CLEAN_DIRS(/tmp /var/tmp /root/.cache/pip /root/.npm) # 各目录保留天数, 默认7天 declare -A KEEP_DAYS KEEP_DAYS[/tmp]3 KEEP_DAYS[/var/tmp]14 # 排除规则的正则表达式 EXCLUDE_PATTERN(\.dockerenv|\.X11-unix|\.ICE-unix|systemd-private.*-(systemd.*)/) log() { echo $(date %Y-%m-%d %H:%M:%S) $* $LOG_FILE } clean_dir() { local dir$1 local keep_days${KEEP_DAYS[$dir]:-7} local threshold${keep_days} if [[ ! -d $dir ]]; then log SKIP: $dir not exists return 0 fi log START: $dir keep_days$keep_days if [[ $DRY_RUN true ]]; then # dry-run: 只打印 find $dir -type f -mtime $threshold \ -regextype posix-extended ! -regex $EXCLUDE_PATTERN \ -printf %p %s bytes\n else # 真实删除删除前统计空间 local before0 local after0 before$(du -sb $dir 2/dev/null | awk {print $1}) find $dir -type f -mtime $threshold \ -regextype posix-extended ! -regex $EXCLUDE_PATTERN \ -delete after$(du -sb $dir 2/dev/null | awk {print $1}) log DONE: $dir released $((before - after)) bytes fi } for d in ${CLEAN_DIRS[]}; do clean_dir $d done log ALL DONE这个脚本有几个关键设计我说一下理由。set -euo pipefail 是必须的。set -e 让脚本在遇到错误时立即退出set -u 直接爆出未定义变量pipefail 保证管道中任一环节失败都会让整个命令失败。这三个组合起来能让你第一时间发现脚本本身的问题而不是让它带病运行。find 命令中 -type f 避免了误删目录。如果直接 -delete目录也会被递归删除风险极大。保留目录结构只删除文件是更稳妥的路径。-delete 相比于 -exec rm {} 更安全因为 find 内置的 -delete 会在内部处理一些边界情况比如先检查目录是否为空避免删非空目录时出错。排除规则用的是 -regextype posix-extended 和 -regex它的作用是保护特殊路径。比如 systemd-private 动态生成的私有目录里面可能存有运行时 socket不能乱删。脚本里的 du 统计可以帮你直观看到每次释放了多少空间日志对排查很有帮助。3.3 第三步配置定时任务脚本写好后剩下的就是让它按时跑起来。Linux 下有两种主流方式cron 和 systemd timer。cron 是最传统的方式配置很简单。编辑 /etc/crontab 或使用 crontab -e加入一行0 2 * * * root /opt/scripts/clean-tmp.sh /var/log/clean-tmp.log 21这表示每天凌晨 2 点执行一次清理脚本。为什么选这个时间因为临时文件清理的最佳窗口是业务低峰期大多数服务在凌晨的负载最低。如果服务器上跑着夜间批处理任务就需要避开那段时间。systemd timer 是更现代的选择。我需要先创建一个 service 单元和一个 timer 单元# /etc/systemd/system/clean-tmp.service [Unit] DescriptionClean temporary files Afternetwork.target [Service] Typeoneshot ExecStart/opt/scripts/clean-tmp.sh# /etc/systemd/system/clean-tmp.timer [Unit] DescriptionRun clean-tmp daily at 02:00 [Timer] OnCalendar*-*-* 02:00:00 Persistenttrue [Install] WantedBytimers.target然后执行systemctl daemon-reload systemctl enable --now clean-tmp.timersystemd timer 相比 cron 有几个优势可以设置 Persistenttrue即使机器当时关机下次开机后也会补跑错过的任务可以用 systemctl status 查看任务最近执行情况日志集中管理方便排查。我个人的建议是新环境优先用 systemd timer老环境沿用 cron 也没问题。如果你用的是 Windows 服务器最常用的方式是“任务计划程序”配合 PowerShell 脚本。PowerShell 里头找临时文件同样简单$threshold (Get-Date).AddDays(-7) Get-ChildItem -Path C:\Windows\Temp -Recurse -File | Where-Object { $_.LastWriteTime -lt $threshold } | Remove-Item -Force -ErrorAction SilentlyContinue在任务计划程序里设置每天执行一次即可。注意 C:\Windows\Temp 有很多文件被系统占用删除时要带上 -ErrorAction SilentlyContinue 忽略失败否则任务会报错。3.4 第四步先演练再上岗脚本和定时任务都配置好了但我不建议直接让它以真实删除模式运行。正确做法是先 dry-run 跑几天。第一轮演练手动执行 --dry-run仔细观察输出内容。重点看两个问题是否有不该删的文件被列出来了是否有应该清理的目录被排除规则挡掉了。发现异常就调整脚本改完再跑。第二轮演练真实删除但选择业务最低峰期手动执行一次。执行前确保已经备份哪怕只是备份脚本并且开启了日志。等脚本连续跑了一周没有异常再把它交给 cron 或 systemd timer 去自动执行。这时候才算真正上岗。我特别想强调一点自动清理系统的“上线”不是一锤子买卖。它应该像监控系统一样需要持续迭代。磁盘增长趋势变化了、业务新增了临时文件目录、某个服务生命周期变短了这些都要反映到清理规则里。我基本上每季度会重盘一遍目录占用同步更新一次脚本。4. 误删与安全清理工具的底线工程自动化清理的恐怖之处在于它不会疲倦也不会犹豫它是按照你的规则去执行每一个删除动作。如果规则有误它会毫不犹豫地把所有命中的文件杀掉。所以守住安全底线是这套系统的生死线。4.1 正在被使用的临时文件会怎样这个现象值得单独讲。很多人在 Linux 上发现一个诡异的事情某个文件明明被删除了但磁盘空间并没有释放。这是因为有一个进程仍然持有该文件的打开句柄。在 Linux 的文件系统语义里文件删除只是把目录项移除但如果文件还被进程打开着它的 inode 和磁盘块并不会立刻释放要等所有句柄关闭之后才真正回收。这意味着什么如果服务在运行时写了一个日志文件你把它删了服务并不会立刻崩溃日志会继续写入这个已经“不存在”的文件里但你再也找不到这个文件了。直到服务重启文件才被真正删除期间磁盘空间一直占用着。排障的时候这种情况非常隐蔽。你 df -h 看磁盘空间没少但目录里文件又不见了很容易怀疑是被病毒入侵或者有日志清理任务出了问题。其实根因可能就是有人在 /tmp 里删了某个正在使用的文件。避免这种问题最直接的办法是用 lsof 检查文件是否被占用。生产环境的清理脚本里我建议加一段# 检查目录中是否有被进程打开的文件 find /var/tmp -type f -mtime 7 -print0 2/dev/null | xargs -0 -r lsof 2/dev/null如果 lsof 输出有结果说明有文件正在使用中应该调整保留策略或者将这些文件排除掉。4.2 权限、符号链接和变量空值三个经典大坑清理脚本里最容易翻车的三个点权限、符号链接和变量空值。权限问题很好理解很多临时目录属于 root普通用户清理不了这需要用 root 或 sudo 执行清理脚本。但问题在于一旦用 root 执行脚本里哪怕有一个地方逻辑混乱后果会被无限放大。我的建议是脚本执行的用户权限要有明确边界比如用独立用户跑清理任务不给不必要的 root 权限。符号链接坑是最隐蔽的。想象一下 /tmp/link 是一个指向 /etc 的符号链接。如果你执行 find /tmp -type d -name link -delete危险不大但如果你在脚本里写了 rm -rf /tmp/*在某个特殊情况下rm 会对符号链接指向的目标进行操作尤其是配合 --no-preserve-root 之类参数时可能把系统关键目录删掉。我见过一次事故有人把 find 的 -exec rm -rf {} ; 误应用于一个包含符号链接的目录结果把链接指向的应用目录整个删了。所以脚本里涉及目录删除时务必加上 -type d 的限制并且显式排除符号链接find ... ! -type l。变量空值是最容易被新手忽视的经典坑。在 bash 脚本中如果某个变量没有赋值默认就是空字符串。假设你写了 rm -rf $DIR/而 $DIR 因为某种原因是空的那么命令行就变成 rm -rf /结果是灾难性的。防范手段很简单脚本开头用 set -u 让未定义变量直接报错或者在删除前断言变量非空[[ -n $DIR ]] || exit 1。顺便说一个和空格相关的坑。文件名里带空格是合法的但很多脚本在拼接路径时没有加引号find 的输出在管道传给 xargs 时会被错误分隔。处理办法是使用 -print0 和 xargs -0或者直接用 -delete。我在 3.2 的脚本里使用 -delete就是考虑到这个。4.3 从“删”到“移”更稳妥的回收站模式对很多场景来说直接物理删除是不必要的冒险。更稳妥的方式是“移动”也就是先设置一个回收桶目录把该清理的文件移动进去观察一段时间没有异常再真正删除。这在生产环境里非常实用。比如我可以把临时文件先移到 /var/tmp/trash保留 14 天后再自动彻底删除。这样即使有误判你还有回旋余地可以手工恢复到原位置。实现起来也不复杂在之前的清理脚本基础上把 -delete 替换成 -exec mv {} /var/tmp/trash/ 即可。我实际用下来这个模式既满足了清理需求又大幅降低了误删造成的不可逆风险。唯一要注意的是回收桶目录自身的清理别让它变成另一个堆积点。给回收桶设置一个更长的保留周期比如 30 天然后定期清一遍。4.4 日志、告警与问题速查自动化清理必须留痕。日志是事后排查的唯一依据。我在脚本里已经把每次清理的路径和释放空间写入 /var/log/clean-tmp.log。如果你有集中日志平台建议把这份日志同步上去如果没有至少确保日志会按天切割避免单个文件无限增大。告警也很重要。单纯把任务挂到 cron 里有效期是“静默失败”如果脚本出错了可能只会默默写个日志就完事。我的做法是在脚本末尾加上简单的健康检查如果本次释放空间为 0或者脚本执行异常就通过 webhook 发送告警到值班群。这不需要复杂的监控平台curl 一条 webhook 就能搞定。梳理一下常见问题方便你快速定位症状可能原因排查方法磁盘空间没减小文件被进程占用未释放lsof 检查句柄、重启服务后观察日志显示删除了但目录还在find 匹配的是文件目录未被删除检查排除规则、目录层级某些目录从未被清理名称包含空格/特殊字符路径拼接失败用 -print0 验证开启 set -u清理任务不执行cron 环境变量或 systemd timer 状态异常systemctl status clean-tmp.timer误删了业务文件排除规则不完整、保留周期过短立即停止任务检查回收桶恢复这些坑我基本上都踩过一遍。最有价值的教训是永远先 dry-run永远先移动后删除永远要留日志。记住这三条自动清理就不会成为灾难制造机。5. 进阶多机、CI 与容器环境里的临时文件治理5.1 给 CI 跑机做磁盘减负CI 系统是临时文件堆积的重灾区。尤其是自建 GitLab Runner 或 Jenkins 节点每跑一次构建都会在 workspace 和 /tmp 里留下大量中间产物。如果构建频率高磁盘空间两三天就能告警。我处理过一台 GitHub Actions 自建 runner每天跑几十次构建每次构建产生的临时文件从几十 MB 到数 GB 不等。最初磁盘 100GB半个月就满了。后来加了双重机制解决第一重是定时清理用上面说的脚本每天早上 4 点清一次第二重是构建结束钩子在每一个 job 收尾时主动清理该构建产生的临时目录。构建结束钩子其实就是 CI 配置文件里的一段代码比如 GitHub Actions 的 post 步骤- name: Cleanup workspace if: always() run: | docker system prune -f sudo rm -rf /tmp/* /var/tmp/* || true sudo rm -rf /home/runner/work/*/node_modules /home/runner/work/*/*/dist || true注意这里用的是 if: always()保证即使构建失败清理也会执行。CI 跑机的治理思路是定时清理兜底构建钩子主动清理双保险。另外 CI 镜像构建阶段清掉包管理器缓存能显著减小镜像体积、缩短推送时间。5.2 多机统一治理从“单机脚本”到“批量执行”当服务器数量多到一定程度逐台配置 cron 是不可维护的。这时候需要把清理规则集中管理。我常用的方案有两种。一种是用 Ansible 之类的配置管理工具。把清理脚本和 timer 单元作为基础设施代码推送到所有目标机器。好处是配置变更可以快速批量生效而且可以统一版本管理。另一种是搭建一个简单的中心化日志和告警管道每台机器跑完清理后把结果汇总到同一处比如收集日志到 Elasticsearch 或用简单的 Webhook 上报。批量执行时有一个重要细节不要在同一时间让所有机器同时清理否则可能会同时触发集中监控平台的告警风暴也可能造成集中的 I/O 冲击。给每台机器的清理时间加上随机偏移量比如 2 点到 3 点之间随机执行是一个成熟的做法。在 Kubernetes 集群里情况稍有不同。节点的临时目录和容器的 emptyDir 卷由 kubelet 管理kubelet 会根据 eviction 阈值自动驱逐容器释放临时存储。但这是“兜底式”的治理主要目的是避免整个节点磁盘写满。业务层面仍然需要自己管理镜像残留和构建缓存。docker system prune 在容器节点上仍然很有用配合定期执行能显著减少磁盘占用。5.3 容器场景的特殊考量容器里的 /tmp 和宿主机上的 /tmp 有本质不同。容器内每个文件系统层都是临时的容器删除后层也随之消失。但也因此产生了一个问题如果你在容器里堆积了大量临时文件而容器长期不重建这些文件会一直占着内存或磁盘。两个实践建议第一容器内尽量避免使用 /tmp 做持久化存储应该使用挂载卷或者 emptyDir第二对跑长时间任务的有状态容器定期重建是比清理内部临时文件更彻底的办法。docker system prune 这个命令我在前面提到了展开说几个参数docker system prune -f --volumes --filter until72h-f 表示不交互确认--volumes 表示同时清理未使用的卷--filter until72h 只清理 72 小时前创建的悬空资源。这个命令特别适合 CI 跑机清理效果立竿见影。但注意默认情况下 docker system prune 不会清理还在使用的镜像和容器这一点安全性还可以不过加上 --volumes 之后要确认没有重要的持久卷被误伤。还有一类常见容器残留是构建缓存。BuildKit 的缓存目录可能非常庞大。对应清理命令是 docker builder prune -f建议在 CI 构建完成后定期执行。总结一下容器的清理哲学优先重建其次治理镜像最后才是容器内部清理。5.4 建立长效机制从“清理”到“预防”临时文件治理的终极目标不是“清得多”而是“产生得少”。当自动化方案稳定运行之后我会建议你花更多时间从源头减少临时文件的产生。具体可以做的事情很多规范日志切割配置 logrotate 的 maxsize 和 rotate统一包管理器缓存目录并设置定期清理在 CI 流水线里对构建产物做归档并自动删除旧版本使用 tmpfs 挂载 /tmp让系统重启时临时空间自动清空对需要的临时数据直接写入内存文件系统而不是写盘再删。以 tmpfs 为例把 /tmp 挂载到内存中读写速度快是一个好处更关键的是重启后内容自动清空完全不需要人为干预。但有个前提内存要够大否则 /tmp 占满内存反而影响系统稳定性。在内存资源充足的服务器上这是一个很优雅的方案。预防思维的本质是把“清理临时文件”这件苦差事从“事后补救”变成“设计时考虑”。你可以在系统设计阶段就把临时文件的存储路径、保留时长、清理责任划分清楚。能做到这一步之后维护的负担会直线下降。回到我自己的体会临时文件自动化治理最被低估的价值其实不是省了多少 GB 磁盘而是让系统行为变得可预期。定时任务每天都在跑日志每天都在记磁盘占用曲线慢慢变得平缓。那种“不知道哪一天磁盘会满”的焦虑感消失之后你才有余力去做更有价值的事。这套方案本身不复杂但它需要你一点点打磨从单机脚本到多机批量从被动清理到主动预防每一步都是在为系统的长期稳定夯实基础。最后再分享一条个人经验每次清理脚本变更后至少保留一周的 dry-run 日志不要急着删除。这些日志是你在排查“是不是清理脚本误删了文件”时最有力的证据。临时文件清理这种操作宁可慢一点、啰嗦一点也千万别拿生产环境做赌注。
先说点实在话。临时文件这东西几乎每个用电脑的人都会碰到但真正把它当回事的人不多。我曾经在一台测试服务器上见过 /tmp 目录里堆了接近 30GB 的垃圾里面全是各种安装包残留、编译中间产物和半年前的日志切片。更麻烦的是这台机器磁盘已经告警了可没人敢手动删——因为谁都不确定里面有没有哪个文件正在被某个服务使用。这种场景相信不少运维和开发朋友都遇到过。临时文件自动化方案说白了就是用一套确定的规则和工具代替“人工不定期清理”这个不靠谱的习惯。它解决的是三个层面的问题磁盘空间被不知不觉吃光、临时文件混乱导致排障困难、以及手动删除时误删正在使用的文件造成事故。这篇文章适合运维工程师、开发者、以及想把自己电脑整理干净但不想天天操心的朋友。我会从方案选型、脚本设计、定时任务配置、误删防护一直讲到 CI/CD 和容器环境里的进阶玩法全程给可复现的命令和配置。1. 临时文件为什么需要一套自动化清理方案1.1 临时文件是怎么悄悄长大的临时文件不是只有一个 /tmp 目录那么简单。按照来源大致能分成几类操作系统运行时会产生的套接字文件、PID 文件、软件安装包残骸包管理器缓存比如 apt、pip、npm、yarn 留下的缓存开发工具的编译产物像 dist、build、target 目录以及 node_modules/.cache还有日志切割后的历史文件。每一类单独看都不大但架不住积少成多。我见过一个很典型的例子一个 Java 项目的编译构建每次会在 /tmp 里留下几百 MB 的中间文件。开发环境跑了几周/tmp 就被撑到了 20GB。还有个前端项目node_modules/.cache 里缓存了几百 MB 的 webpack 持久化缓存磁盘空间莫名其妙就少了。这种问题最大的迷惑性在于你根本不知道是谁写的也不知道什么时候写的排查起来特别费劲。如果是在 Linux 服务器上inode 耗尽比磁盘满更隐蔽。一个目录里塞了上百万个小文件df -h 看着还有空间但 df -i 已经 100% 了这时候任何新文件都创建不了系统行为变得非常诡异。这类问题一旦发生手动清理难度极大没有自动化方案几乎只能靠重建文件系统来恢复。1.2 手动清理的三个硬伤手动清理临时文件看起来简单实际做起来有三个绕不过去的硬伤。第一个是频率问题。人一定会忘记。磁盘告警才想起来去清理往往已经是火烧眉毛的时刻。我见过很多人平时不关心等到发现磁盘满了才临时抱佛脚地删文件删完过两个星期又满了陷入无限循环。第二个是判断问题。哪些临时文件可以删、哪些不能删需要根据文件的修改时间、访问时间、当前是否被进程占用来判断。手动操作时没人愿意逐项分析结果要么一刀切乱删要么干脆一个都不敢动。第三个是路径问题。临时文件分布在系统的各个角落从 /tmp、/var/tmp 到用户目录下的 .cache、项目目录里的构建产物甚至容器运行时的 overlay 层。手动清理很难覆盖全而且每次执行的操作命令可能都不一样最终效果完全不可控。1.3 自动化方案解决的核心问题自动化清理最大的价值不是“替你点了删除按钮”而是把清理这回事从“随机事件”变成“确定性行为”。确定性的含义包括定期执行、规则明确、操作可审计、结果可追踪。规则明确指的是你可以精确指定哪些目录、按什么条件、删除多老的文件。比如“删除 /tmp 下超过 7 天没修改过的文件”这是一条可执行、可验证的规则。操作可审计指的是每次执行都留下日志删了多少文件、释放了多少空间都记录在案出问题能回溯。结果可追踪则意味着你能通过日志和告警知道清理动作是否成功、是否有异常。一旦这套东西搭建起来它就能自己运转不再依赖人工的临场判断。我自己的习惯是“先盘家底、再定规则、后上自动化”下面几个章节就是围绕这个思路展开的。2. 方案选型从“能用”到“好用”2.1 系统自带方案不用白不用如果只看 Linux 系统本身其实已经内置了几套基础的临时文件管理机制其中最值得了解的是 systemd-tmpfiles 和 tmpreaper。systemd-tmpfiles 通过配置文件来声明哪些目录要清理、按什么规则清理。配置文件放在 /etc/tmpfiles.d/ 下语法很直白。举个例子# /etc/tmpfiles.d/clean-tmp.conf d /tmp 1777 root root 7d D /var/tmp 1777 root root 30d第一行表示 /tmp 目录保留 7 天超过这个期限的文件会被 systemd-tmpfiles --clean 处理。第二行的 D 表示目录本身和里面的内容一起清理保留周期 30 天。这个方案的好处是零额外依赖、声明式管理适合规则不复杂的场景。tmpreaper 则是传统 tmpwatch 的增强版用起来更灵活。比如这条命令tmpreaper 7d /tmp含义是删除 /tmp 下 7 天未访问的文件。tmpreaper 的优势在于它考虑了很多边界情况比如不会去动正在被进程使用的文件、知道怎么处理符号链接、还支持排除规则。不过在不少现代 Linux 发行版里systemd 已经成为默认 init 系统systemd-tmpfiles 明显是更“原汁原味”的选择。还有一个很实用的系统机制是 logrotate。它管理的是日志文件不是普通临时文件但日志和临时文件经常混在一起。给日志配置好按大小或日期切割再配合 rotate 份数限制能从源头上避免日志文件无限增长。很多生产事故其实就是日志把磁盘写满了。这两类系统方案的共同问题是“够用但不够细”。如果只有几条静态规则那直接用 systemd-tmpfiles 就够了如果你需要按目录、按条件、按项目自定义复杂的清理逻辑就得用脚本。2.2 脚本方案最灵活也最危险脚本方案的核心就是两个工具find 负责查找cron 或 systemd timer 负责定时执行。它灵活在哪里你可以自由组合路径、时间条件、文件类型、大小条件还可以在删除前做任何你想做的预处理。但是脚本方案也是最危险的。原因在于find 命令是一个纯粹的“执行者”它不会理解文件是否重要。一条命令写错可能把不该删的全删了。比如很多人刚接触时会写 find / -name *.log -exec rm {} ;这行命令会去系统里找所有 .log 文件然后删掉包括某些应用正在写入的日志后果不堪设想。因此脚本方案的准入门槛是你必须严格遵守“先 dry-run、再真实执行”的原则。dry-run 就是只打印会删除哪些文件不真正执行删除。这一步能帮你提前发现规则写错的问题。下面这行命令就是 dry-run 的典型写法find /tmp -type f -mtime 7 -print先看输出确认列出来的文件全是该清的再把 -print 换成 -delete或者接上 -exec rm 来真正执行。2.3 工具链方案处理特定生态的残留系统方案和脚本方案解决的是通用临时文件。但在真实场景里最有价值的是针对特定生态做清理。我举例说明几类项目构建产物。node 项目里的 node_modules/.cache、dist、buildJava 项目里的 targetPython 项目里的pycache。这些目录量大、增长快而且重建成本低。清理它们通常不用犹豫。可以写一个项目级清理脚本当项目不再活跃时自动清掉这些构建缓存。包管理器缓存。pip 的 ~/.cache/pipnpm 的 ~/.npmapt 的 /var/cache/apt。这些缓存删掉之后下次安装包会重新下载但在磁盘紧张的时候它们是最好的“出血点”。我通常在 CI 镜像构建的最后阶段清掉这些缓存能显著减小镜像体积。Docker 相关的残留。docker system prune -f 能清理悬空镜像和停止的容器/var/lib/docker/overlay2 里堆积的层文件是磁盘大户。配合日志轮转和镜像保留策略能避免 Docker 占据大量磁盘。每种生态都有自己的一套清理规则脚本的灵活性在这里体现得淋漓尽致。但要注意工具链方案往往涉及特定业务逻辑最好能结合项目实际情况做保留策略而不是一刀切全删。2.4 选型建议与对比我直接给一个决策表格方便你对号入座方案优势劣势适用场景systemd-tmpfiles零依赖、声明式、系统原生规则表达能力有限常规 /tmp 和 /var/tmp 清理tmpreaper安全边界处理较好、主动检查占用部分发行版需额外安装传统服务器、复杂排除规则自写脚本 cron/timer完全可控、可定制业务逻辑风险高依赖编写者水平多目录、混合规则的项目环境docker system prune专攻容器残留、集成度高只处理 Docker 生态CI 跑机、容器化部署环境商业/平台级工具集中管理、告警完善引入成本高多机、多团队的大规模治理选型的核心原则是盘子里有多少菜决定你用多大锅。单机服务器上几条规则别一上来就上重量级平台方案而真正的大规模集群环境光靠几个 cron 脚本也撑不住这时候才需要集中管理和统一的度量体系。3. 实操搭一套最小可用的自动清理系统这一节我会完整走一遍实际搭建流程从盘家底、写规则到挂定时任务全部是可复现的命令和配置。我先说明一下我的环境假设一台 Ubuntu 22.04 服务器Docker 和 Node 环境都有目标是每天自动清理各类临时文件。3.1 第一步盘点目录和设计保留策略在动任何命令之前先花半小时做一次“家底盘点”。你需要明确知道这台机器上哪些目录是真正需要清理的以及每个目录的合理保留周期。我推荐的盘点方法是先全盘扫一遍目录占用定位最大的几个目录du -h --max-depth1 /tmp 2/dev/null | sort -hr | head -20 du -h --max-depth1 /var/tmp 2/dev/null | sort -hr | head -20 du -h --max-depth2 ~/.cache 2/dev/null | sort -hr | head -20然后根据目录实际内容和业务要求给每个目录设定保留周期。我给一套通用的初始策略你可以直接抄目录保留周期说明/tmp1~3 天系统临时文件生命周期极短/var/tmp7~30 天相对持久但也不应长期堆积~/.cache/pip、~/.npm30 天重新下载成本低但没必要天天删项目 target、dist、node_modules/.cache7 天构建产物可重建日志切割后的旧文件7~14 天由 logrotate 管理更佳Docker 悬空镜像立即清理docker system prune 处理注意保留周期的设定不是拍脑袋。太短可能导致正在使用的文件被删太长则清理没意义。我的经验是“宁保守勿激进”初次设定可以给到双倍周期运行一两周观察后再逐步缩短。3.2 第二步写核心清理脚本脚本是整套系统的核心。我给出一个我实际在用的版本做了精简但核心逻辑完整。它支持日志输出、支持排除规则、也支持 dry-run 模式。#!/usr/bin/env bash # 临时文件自动清理脚本 # 用法: # ./clean-tmp.sh --dry-run # 只打印将删除的文件不实际删除 # ./clean-tmp.sh # 真实执行清理 set -euo pipefail DRY_RUNfalse if [[ ${1:-} --dry-run ]]; then DRY_RUNtrue fi LOG_FILE/var/log/clean-tmp.log # 需要清理的目录列表空格分隔 CLEAN_DIRS(/tmp /var/tmp /root/.cache/pip /root/.npm) # 各目录保留天数, 默认7天 declare -A KEEP_DAYS KEEP_DAYS[/tmp]3 KEEP_DAYS[/var/tmp]14 # 排除规则的正则表达式 EXCLUDE_PATTERN(\.dockerenv|\.X11-unix|\.ICE-unix|systemd-private.*-(systemd.*)/) log() { echo $(date %Y-%m-%d %H:%M:%S) $* $LOG_FILE } clean_dir() { local dir$1 local keep_days${KEEP_DAYS[$dir]:-7} local threshold${keep_days} if [[ ! -d $dir ]]; then log SKIP: $dir not exists return 0 fi log START: $dir keep_days$keep_days if [[ $DRY_RUN true ]]; then # dry-run: 只打印 find $dir -type f -mtime $threshold \ -regextype posix-extended ! -regex $EXCLUDE_PATTERN \ -printf %p %s bytes\n else # 真实删除删除前统计空间 local before0 local after0 before$(du -sb $dir 2/dev/null | awk {print $1}) find $dir -type f -mtime $threshold \ -regextype posix-extended ! -regex $EXCLUDE_PATTERN \ -delete after$(du -sb $dir 2/dev/null | awk {print $1}) log DONE: $dir released $((before - after)) bytes fi } for d in ${CLEAN_DIRS[]}; do clean_dir $d done log ALL DONE这个脚本有几个关键设计我说一下理由。set -euo pipefail 是必须的。set -e 让脚本在遇到错误时立即退出set -u 直接爆出未定义变量pipefail 保证管道中任一环节失败都会让整个命令失败。这三个组合起来能让你第一时间发现脚本本身的问题而不是让它带病运行。find 命令中 -type f 避免了误删目录。如果直接 -delete目录也会被递归删除风险极大。保留目录结构只删除文件是更稳妥的路径。-delete 相比于 -exec rm {} 更安全因为 find 内置的 -delete 会在内部处理一些边界情况比如先检查目录是否为空避免删非空目录时出错。排除规则用的是 -regextype posix-extended 和 -regex它的作用是保护特殊路径。比如 systemd-private 动态生成的私有目录里面可能存有运行时 socket不能乱删。脚本里的 du 统计可以帮你直观看到每次释放了多少空间日志对排查很有帮助。3.3 第三步配置定时任务脚本写好后剩下的就是让它按时跑起来。Linux 下有两种主流方式cron 和 systemd timer。cron 是最传统的方式配置很简单。编辑 /etc/crontab 或使用 crontab -e加入一行0 2 * * * root /opt/scripts/clean-tmp.sh /var/log/clean-tmp.log 21这表示每天凌晨 2 点执行一次清理脚本。为什么选这个时间因为临时文件清理的最佳窗口是业务低峰期大多数服务在凌晨的负载最低。如果服务器上跑着夜间批处理任务就需要避开那段时间。systemd timer 是更现代的选择。我需要先创建一个 service 单元和一个 timer 单元# /etc/systemd/system/clean-tmp.service [Unit] DescriptionClean temporary files Afternetwork.target [Service] Typeoneshot ExecStart/opt/scripts/clean-tmp.sh# /etc/systemd/system/clean-tmp.timer [Unit] DescriptionRun clean-tmp daily at 02:00 [Timer] OnCalendar*-*-* 02:00:00 Persistenttrue [Install] WantedBytimers.target然后执行systemctl daemon-reload systemctl enable --now clean-tmp.timersystemd timer 相比 cron 有几个优势可以设置 Persistenttrue即使机器当时关机下次开机后也会补跑错过的任务可以用 systemctl status 查看任务最近执行情况日志集中管理方便排查。我个人的建议是新环境优先用 systemd timer老环境沿用 cron 也没问题。如果你用的是 Windows 服务器最常用的方式是“任务计划程序”配合 PowerShell 脚本。PowerShell 里头找临时文件同样简单$threshold (Get-Date).AddDays(-7) Get-ChildItem -Path C:\Windows\Temp -Recurse -File | Where-Object { $_.LastWriteTime -lt $threshold } | Remove-Item -Force -ErrorAction SilentlyContinue在任务计划程序里设置每天执行一次即可。注意 C:\Windows\Temp 有很多文件被系统占用删除时要带上 -ErrorAction SilentlyContinue 忽略失败否则任务会报错。3.4 第四步先演练再上岗脚本和定时任务都配置好了但我不建议直接让它以真实删除模式运行。正确做法是先 dry-run 跑几天。第一轮演练手动执行 --dry-run仔细观察输出内容。重点看两个问题是否有不该删的文件被列出来了是否有应该清理的目录被排除规则挡掉了。发现异常就调整脚本改完再跑。第二轮演练真实删除但选择业务最低峰期手动执行一次。执行前确保已经备份哪怕只是备份脚本并且开启了日志。等脚本连续跑了一周没有异常再把它交给 cron 或 systemd timer 去自动执行。这时候才算真正上岗。我特别想强调一点自动清理系统的“上线”不是一锤子买卖。它应该像监控系统一样需要持续迭代。磁盘增长趋势变化了、业务新增了临时文件目录、某个服务生命周期变短了这些都要反映到清理规则里。我基本上每季度会重盘一遍目录占用同步更新一次脚本。4. 误删与安全清理工具的底线工程自动化清理的恐怖之处在于它不会疲倦也不会犹豫它是按照你的规则去执行每一个删除动作。如果规则有误它会毫不犹豫地把所有命中的文件杀掉。所以守住安全底线是这套系统的生死线。4.1 正在被使用的临时文件会怎样这个现象值得单独讲。很多人在 Linux 上发现一个诡异的事情某个文件明明被删除了但磁盘空间并没有释放。这是因为有一个进程仍然持有该文件的打开句柄。在 Linux 的文件系统语义里文件删除只是把目录项移除但如果文件还被进程打开着它的 inode 和磁盘块并不会立刻释放要等所有句柄关闭之后才真正回收。这意味着什么如果服务在运行时写了一个日志文件你把它删了服务并不会立刻崩溃日志会继续写入这个已经“不存在”的文件里但你再也找不到这个文件了。直到服务重启文件才被真正删除期间磁盘空间一直占用着。排障的时候这种情况非常隐蔽。你 df -h 看磁盘空间没少但目录里文件又不见了很容易怀疑是被病毒入侵或者有日志清理任务出了问题。其实根因可能就是有人在 /tmp 里删了某个正在使用的文件。避免这种问题最直接的办法是用 lsof 检查文件是否被占用。生产环境的清理脚本里我建议加一段# 检查目录中是否有被进程打开的文件 find /var/tmp -type f -mtime 7 -print0 2/dev/null | xargs -0 -r lsof 2/dev/null如果 lsof 输出有结果说明有文件正在使用中应该调整保留策略或者将这些文件排除掉。4.2 权限、符号链接和变量空值三个经典大坑清理脚本里最容易翻车的三个点权限、符号链接和变量空值。权限问题很好理解很多临时目录属于 root普通用户清理不了这需要用 root 或 sudo 执行清理脚本。但问题在于一旦用 root 执行脚本里哪怕有一个地方逻辑混乱后果会被无限放大。我的建议是脚本执行的用户权限要有明确边界比如用独立用户跑清理任务不给不必要的 root 权限。符号链接坑是最隐蔽的。想象一下 /tmp/link 是一个指向 /etc 的符号链接。如果你执行 find /tmp -type d -name link -delete危险不大但如果你在脚本里写了 rm -rf /tmp/*在某个特殊情况下rm 会对符号链接指向的目标进行操作尤其是配合 --no-preserve-root 之类参数时可能把系统关键目录删掉。我见过一次事故有人把 find 的 -exec rm -rf {} ; 误应用于一个包含符号链接的目录结果把链接指向的应用目录整个删了。所以脚本里涉及目录删除时务必加上 -type d 的限制并且显式排除符号链接find ... ! -type l。变量空值是最容易被新手忽视的经典坑。在 bash 脚本中如果某个变量没有赋值默认就是空字符串。假设你写了 rm -rf $DIR/而 $DIR 因为某种原因是空的那么命令行就变成 rm -rf /结果是灾难性的。防范手段很简单脚本开头用 set -u 让未定义变量直接报错或者在删除前断言变量非空[[ -n $DIR ]] || exit 1。顺便说一个和空格相关的坑。文件名里带空格是合法的但很多脚本在拼接路径时没有加引号find 的输出在管道传给 xargs 时会被错误分隔。处理办法是使用 -print0 和 xargs -0或者直接用 -delete。我在 3.2 的脚本里使用 -delete就是考虑到这个。4.3 从“删”到“移”更稳妥的回收站模式对很多场景来说直接物理删除是不必要的冒险。更稳妥的方式是“移动”也就是先设置一个回收桶目录把该清理的文件移动进去观察一段时间没有异常再真正删除。这在生产环境里非常实用。比如我可以把临时文件先移到 /var/tmp/trash保留 14 天后再自动彻底删除。这样即使有误判你还有回旋余地可以手工恢复到原位置。实现起来也不复杂在之前的清理脚本基础上把 -delete 替换成 -exec mv {} /var/tmp/trash/ 即可。我实际用下来这个模式既满足了清理需求又大幅降低了误删造成的不可逆风险。唯一要注意的是回收桶目录自身的清理别让它变成另一个堆积点。给回收桶设置一个更长的保留周期比如 30 天然后定期清一遍。4.4 日志、告警与问题速查自动化清理必须留痕。日志是事后排查的唯一依据。我在脚本里已经把每次清理的路径和释放空间写入 /var/log/clean-tmp.log。如果你有集中日志平台建议把这份日志同步上去如果没有至少确保日志会按天切割避免单个文件无限增大。告警也很重要。单纯把任务挂到 cron 里有效期是“静默失败”如果脚本出错了可能只会默默写个日志就完事。我的做法是在脚本末尾加上简单的健康检查如果本次释放空间为 0或者脚本执行异常就通过 webhook 发送告警到值班群。这不需要复杂的监控平台curl 一条 webhook 就能搞定。梳理一下常见问题方便你快速定位症状可能原因排查方法磁盘空间没减小文件被进程占用未释放lsof 检查句柄、重启服务后观察日志显示删除了但目录还在find 匹配的是文件目录未被删除检查排除规则、目录层级某些目录从未被清理名称包含空格/特殊字符路径拼接失败用 -print0 验证开启 set -u清理任务不执行cron 环境变量或 systemd timer 状态异常systemctl status clean-tmp.timer误删了业务文件排除规则不完整、保留周期过短立即停止任务检查回收桶恢复这些坑我基本上都踩过一遍。最有价值的教训是永远先 dry-run永远先移动后删除永远要留日志。记住这三条自动清理就不会成为灾难制造机。5. 进阶多机、CI 与容器环境里的临时文件治理5.1 给 CI 跑机做磁盘减负CI 系统是临时文件堆积的重灾区。尤其是自建 GitLab Runner 或 Jenkins 节点每跑一次构建都会在 workspace 和 /tmp 里留下大量中间产物。如果构建频率高磁盘空间两三天就能告警。我处理过一台 GitHub Actions 自建 runner每天跑几十次构建每次构建产生的临时文件从几十 MB 到数 GB 不等。最初磁盘 100GB半个月就满了。后来加了双重机制解决第一重是定时清理用上面说的脚本每天早上 4 点清一次第二重是构建结束钩子在每一个 job 收尾时主动清理该构建产生的临时目录。构建结束钩子其实就是 CI 配置文件里的一段代码比如 GitHub Actions 的 post 步骤- name: Cleanup workspace if: always() run: | docker system prune -f sudo rm -rf /tmp/* /var/tmp/* || true sudo rm -rf /home/runner/work/*/node_modules /home/runner/work/*/*/dist || true注意这里用的是 if: always()保证即使构建失败清理也会执行。CI 跑机的治理思路是定时清理兜底构建钩子主动清理双保险。另外 CI 镜像构建阶段清掉包管理器缓存能显著减小镜像体积、缩短推送时间。5.2 多机统一治理从“单机脚本”到“批量执行”当服务器数量多到一定程度逐台配置 cron 是不可维护的。这时候需要把清理规则集中管理。我常用的方案有两种。一种是用 Ansible 之类的配置管理工具。把清理脚本和 timer 单元作为基础设施代码推送到所有目标机器。好处是配置变更可以快速批量生效而且可以统一版本管理。另一种是搭建一个简单的中心化日志和告警管道每台机器跑完清理后把结果汇总到同一处比如收集日志到 Elasticsearch 或用简单的 Webhook 上报。批量执行时有一个重要细节不要在同一时间让所有机器同时清理否则可能会同时触发集中监控平台的告警风暴也可能造成集中的 I/O 冲击。给每台机器的清理时间加上随机偏移量比如 2 点到 3 点之间随机执行是一个成熟的做法。在 Kubernetes 集群里情况稍有不同。节点的临时目录和容器的 emptyDir 卷由 kubelet 管理kubelet 会根据 eviction 阈值自动驱逐容器释放临时存储。但这是“兜底式”的治理主要目的是避免整个节点磁盘写满。业务层面仍然需要自己管理镜像残留和构建缓存。docker system prune 在容器节点上仍然很有用配合定期执行能显著减少磁盘占用。5.3 容器场景的特殊考量容器里的 /tmp 和宿主机上的 /tmp 有本质不同。容器内每个文件系统层都是临时的容器删除后层也随之消失。但也因此产生了一个问题如果你在容器里堆积了大量临时文件而容器长期不重建这些文件会一直占着内存或磁盘。两个实践建议第一容器内尽量避免使用 /tmp 做持久化存储应该使用挂载卷或者 emptyDir第二对跑长时间任务的有状态容器定期重建是比清理内部临时文件更彻底的办法。docker system prune 这个命令我在前面提到了展开说几个参数docker system prune -f --volumes --filter until72h-f 表示不交互确认--volumes 表示同时清理未使用的卷--filter until72h 只清理 72 小时前创建的悬空资源。这个命令特别适合 CI 跑机清理效果立竿见影。但注意默认情况下 docker system prune 不会清理还在使用的镜像和容器这一点安全性还可以不过加上 --volumes 之后要确认没有重要的持久卷被误伤。还有一类常见容器残留是构建缓存。BuildKit 的缓存目录可能非常庞大。对应清理命令是 docker builder prune -f建议在 CI 构建完成后定期执行。总结一下容器的清理哲学优先重建其次治理镜像最后才是容器内部清理。5.4 建立长效机制从“清理”到“预防”临时文件治理的终极目标不是“清得多”而是“产生得少”。当自动化方案稳定运行之后我会建议你花更多时间从源头减少临时文件的产生。具体可以做的事情很多规范日志切割配置 logrotate 的 maxsize 和 rotate统一包管理器缓存目录并设置定期清理在 CI 流水线里对构建产物做归档并自动删除旧版本使用 tmpfs 挂载 /tmp让系统重启时临时空间自动清空对需要的临时数据直接写入内存文件系统而不是写盘再删。以 tmpfs 为例把 /tmp 挂载到内存中读写速度快是一个好处更关键的是重启后内容自动清空完全不需要人为干预。但有个前提内存要够大否则 /tmp 占满内存反而影响系统稳定性。在内存资源充足的服务器上这是一个很优雅的方案。预防思维的本质是把“清理临时文件”这件苦差事从“事后补救”变成“设计时考虑”。你可以在系统设计阶段就把临时文件的存储路径、保留时长、清理责任划分清楚。能做到这一步之后维护的负担会直线下降。回到我自己的体会临时文件自动化治理最被低估的价值其实不是省了多少 GB 磁盘而是让系统行为变得可预期。定时任务每天都在跑日志每天都在记磁盘占用曲线慢慢变得平缓。那种“不知道哪一天磁盘会满”的焦虑感消失之后你才有余力去做更有价值的事。这套方案本身不复杂但它需要你一点点打磨从单机脚本到多机批量从被动清理到主动预防每一步都是在为系统的长期稳定夯实基础。最后再分享一条个人经验每次清理脚本变更后至少保留一周的 dry-run 日志不要急着删除。这些日志是你在排查“是不是清理脚本误删了文件”时最有力的证据。临时文件清理这种操作宁可慢一点、啰嗦一点也千万别拿生产环境做赌注。
