我盯上临时文件清理这个需求是因为一次实打实的磁盘灾难。C盘只剩不到5GB那个周末我又急着装一个大型软件安装程序写到一半报磁盘空间不足装到一半的东西停在那里系统索引、浏览器缓存、各种日志全都挤在临时目录里。我翻了半天发现系统自带的磁盘清理只处理它认识的那部分文件真正占空间的大头——各种软件运行期间散落在临时目录里的包、缓存、分块文件——它根本不管。那之后我就决定自己写一个跨平台临时文件清理工具不依赖各家系统那套割裂的清理逻辑。这个工具的定位很直接只要是临时目录里的东西按规则筛选后该清的清、该跳过的跳过、该留的留。它适合有这类痛点的人——常年在Windows和Linux两套环境之间切来切去或者帮家里人、帮公司同事维护电脑又或者纯粹想守住磁盘上一块整洁的阵地。这篇文章我会把整套思路和踩坑过程完整写出来从目录识别、安全筛选、删除兜底到打包分发每一步都是实测过的方案。1. 临时文件为什么值得专门写代码清理先说清楚我反对的几种做法再讲这个工具应该怎么设计不然你可能会直接写一个删掉所有东西的脚本然后哪天对着误删的数据欲哭无泪。1.1 系统自带清理能力的盲区Windows 自带的磁盘清理和 macOS 的优化存储本质上都依赖系统内置的数据库知道自己哪些文件是缓存、哪些是临时文件。可现实是第三方软件的临时文件没那么听话。举几个我见过的实际例子浏览器下载到一半的.crdownload、.part分块文件任务取消后没人清理长期堆在临时目录里。安装包解压器在%TEMP%下建的is-xxxxx.tmp目录安装结束异常退出时这些目录不会自动删除。Java 虚拟机创建的hsperfdata_用户名目录进程杀掉后残留。pytest、cmake、各种构建工具在系统临时目录下建的测试缓存和对象文件。我在一台跑了半年的 Windows 机器上扫描临时目录总占用接近34GB。系统自带清理统计出来只有几百MB剩余全被忽略了。macOS 的/var/folders/...也不遑多让Linux 的/tmp平时看起来干净但遇到长期运行的服务器进程积累的文件数量同样惊人。1.2 我看到的核心瓶颈完整的跨平台临时文件清理工具必须处理三件事目录识别Windows、macOS、Linux 的临时目录位置不一样变量来源也不一样不能写死路径。安全筛选临时目录里不是所有东西都能删正在被进程占用的文件、正在写入中的文件、用户误放的重要数据都必须有保护机制。执行兜底删除过程中会遇到权限不足、文件被锁、符号链接指向外部目录这些异常一键脚本会直接崩溃工具必须逐项处理并继续。明白这三点之后你会发现临时文件清理不是一个删目录的活而是一个识别、筛选、保护、兜底的系统工程。我这篇文章的代码和实践也都是围绕这套逻辑展开的。2. 技术选型跨平台清理工具用什么写最划算动手之前我也纠结过一轮写 Shell 脚本还是用 Go最后选了 Python。这个选择不是拍脑袋背后有几条很实在的理由。2.1 为什么不用 Shell也不用 Go 一把梭Shell 脚本的跨平台能力实在弱。在 Linux/macOS 上是rm -rf /tmp/*的天下但到 Windows 上就脱节了要么依赖 Git Bash要么依赖 WSL分发成本陡增。你可以让目标机器装 WSL问题是这不是一个随手就能用的工具而是要带给普通用户或运维同事的工具多一层依赖就多一个不用的理由。Go 完全可行但开发效率不如 Python。Go 编译出来的单二进制文件确实漂亮不依赖解释器体积也小。可临时文件清理这种工具核心逻辑倒不复杂复杂的是各种平台特性和异常处理Python 标准库打包得相对完整改一版规则马上能跑不需要为了读一个环境变量去查一堆系统包。如果你后续想让规则可配置化、加个 JSON 配置、对接 Web 界面Python 的迭代速度优势更明显。2.2 用到的核心庫以及各自的责任我最终的依赖列表保持在纯标准库级别一个第三方包都不用。这样在用户机器上跑起来最简单也方便打包模块职责tempfile获取当前系统的临时目录跨平台兼容的关键platform识别 Windows / Linux / macOS决定不同的策略分支os/os.scandir遍历目录、读取文件状态、删除文件pathlib统一路径操作规避 Windows 反斜杠带来的各类坑shutil目录树删除rmtreeargparse命令行参数比如--dry-run、--older-thanlogging输出清理日志方便排查json读配置文件管理白名单/黑名单规则关键是tempfile.gettempdir()。它在 Windows 上会依次检查TMP、TEMP、USERPROFILE等环境变量在 Linux/macOS 上会检查TMPDIR环境变量最终返回一个确定的临时目录。直接用它比自己在代码里拼环境变量名更稳。3. 核心实现识别、筛选、执行三步走写代码的顺序很讲究——不要一开始就写删除逻辑。我建议严格按照识别临时目录 → 统计并筛选 → 执行删除的节奏推进每步都单独验证。3.1 第一步跨平台定位临时目录下面的函数可以同时收集用户级临时目录和系统级临时目录import os import platform import tempfile from pathlib import Path def collect_temp_roots() - list[Path]: roots [] system platform.system() # 用户级临时目录三个系统都有 user_tmp Path(tempfile.gettempdir()).resolve() if not user_tmp.exists(): user_tmp.mkdir(parentsTrue, exist_okTrue) roots.append(user_tmp) # 系统级临时目录 if system Windows: windir os.environ.get(SystemRoot, rC:\Windows) roots.append(Path(windir) / Temp) elif system Darwin: # macOS 的每个用户还有独立缓存域路径中包含随机 ID roots.append(Path(/var/folders)) else: roots.append(Path(/tmp)) roots.append(Path(/var/tmp)) return sorted(set(roots), keylambda p: str(p))请注意resolve()。在 macOS 上/tmp其实是指向/private/tmp的符号链接如果我们的代码不 resolve后续判断这个路径是否在我允许的临时目录集合内时会出现同一个目录被反复识别的混乱。先把路径规范化后面的所有比较才有意义。3.2 第二步安全筛选策略的设计直接遍历目录然后删掉所有文件非常危险。我设计的筛选规则一共有四层缺一不可年龄阈值文件修改时间距今超过 N 天默认 7 天。正在使用的临时文件往往 mtime 很新这个阈值能把它们保护住。大小阈值小于 1MB 的文件跳过这个不一定我会作为可选参数但如果文件大小还在剧烈变化中说明可能正在写入要跳过。目录保护名单临时目录下若存在.git、important、keep等名称的目录默认不删除除非用户显式传入--force-keep。删除范围校验所有要删除的路径必须位于已识别的临时根目录内绝不允许删除根目录之外的目标。筛选逻辑大致如下from datetime import datetime, timedelta import os from pathlib import Path def _is_old_enough(path: Path, older_than_days: int) - bool: try: mtime datetime.fromtimestamp(path.stat().st_mtime) except FileNotFoundError: return True except OSError: return False return mtime datetime.now() - timedelta(daysolder_than_days) def _is_inside_roots(path: Path, roots: list[Path]) - bool: resolved path.resolve() for root in roots: try: if resolved.is_relative_to(root.resolve()): return True except ValueError: continue return False这段代码有一个细节值得注意用st_mtime而不是st_atime。Linux 的 atime 更新策略是按需更新的有些发行版默认relatime这意味着一个文件可能昨天被读过但 atime 还停留在几个月前。如果按 atime 判断容易把常用文件误判成很久没碰。mtime 在这个场景下稳定得多。3.3 第三步删除与异常兜底到了真正删除这一步设计原则是能删就删删不了的记下来绝不能循环卡死。import shutil import logging logger logging.getLogger(tmpclean) def safe_remove(path: Path) - tuple[bool, str]: try: if path.is_dir(): shutil.rmtree(path, ignore_errorsFalse) else: path.unlink() return True, except PermissionError as exc: return False, fpermission: {exc} except OSError as exc: return False, fos error: {exc}这里有一个关键点shutil.rmtree如果遇到目录内某个文件被占用会抛出异常而且可能删掉一部分文件、留一部分文件——这个时候你重试整个目录树不一定有用因为文件可能仍被进程锁着。更稳妥的做法是先用os.scandir从底层遍历对每个文件单独删除对每个空目录再用os.rmdir目录删不掉也没关系留着下次再跑。下面的清理函数体现了这个思路def clean_tree(root: Path, roots: list[Path], older_than_days: int): removed_count 0 failed_log [] for entry in sorted(os.scandir(root), keylambda e: e.name): path Path(entry.path) # 防止符号链接逃逸 if path.is_symlink(): if _is_old_enough(path, older_than_days): try: path.unlink() removed_count 1 except OSError as exc: failed_log.append((str(path), str(exc))) continue try: if entry.is_dir(follow_symlinksFalse) and not entry.is_symlink(): if _is_inside_roots(path, roots) and _is_old_enough(path, older_than_days): ok, msg safe_remove(path) if ok: removed_count 1 else: failed_log.append((str(path), msg)) elif entry.is_file(follow_symlinksFalse): if _is_old_enough(path, older_than_days): ok, msg safe_remove(path) if ok: removed_count 1 else: failed_log.append((str(path), msg)) except OSError as exc: failed_log.append((str(path), str(exc))) return removed_count, failed_log核心保护逻辑在前面加了一层先判断路径在不在根目录集合内。我用entry.is_dir(follow_symlinksFalse)和entry.is_symlink()双保险避免符号链接目录通过is_dir()被误判成真目录然后被rmtree一路删到外部去。Windows 上还要额外小心 junction/reparse point这类假目录按软链接处理只删链接本身。4. 实测中踩过的坑权限、占用、符号链接与中文路径这一部分是我最想强调的。代码看起来简单但每换一个操作系统都有不同的问题等着你。我在三个平台上分别跑过以下全是真实遇过的坑。4.1 Windows 下的文件占用与 PermissionErrorWindows 上删除临时文件最常见的失败就是文件被占用。比如浏览器某个下载进程还握着.crdownload或者杀毒软件正在扫描某个.exe。这时os.remove和shutil.rmtree都会抛PermissionError。我的对策是加一个重试机制import time def safe_remove_with_retry(path: Path, retries: int 3, delay: float 0.5): for attempt in range(retries): ok, msg safe_remove(path) if ok: return True, msg if attempt retries - 1: time.sleep(delay) logger.warning(删失败重试 %s: %s, path, msg) return False, msg实测下来对于杀毒软件短时间扫描导致的瞬时占用重试很有效。对于长时间占用比如某个服务持续锁定文件重试也没用那就跳过并记录不要影响其他清理。清理工具不是修复工具它不该因为个别顽固文件就卡死。4.2 Linux/macOS 下的符号链接陷阱Linux 的/tmp里经常有符号链接Web 服务、容器运行时都会在里面留下指向持久卷的链接。如果你的代码没有检查符号链接直接使用shutil.rmtree——虽然它默认不会跟随软链接但在某些边界情况比如路径带.或..组件仍可能出问题。更严峻的是 macOS 的/var/folders结构。每个用户有独立的临时目录里面大量使用符号链接。我建议所有对目录的判断都加一个follow_symlinksFalse的标志。例如entry.is_dir(follow_symlinksFalse)只有真目录才返回 True软链接或 junction 一律只做unlink处理。这样就算临时目录里出现一个指向/home/user/documents的链接也只是删掉链接绝不触碰目标数据。4.3 中文路径与编码问题Windows 控制台和历史遗留程序对编码的处理比较混乱临时目录里可能出现中文或特殊字符的文件名。Python 3 内部用 Unicode没问题但把文件名拼进报错信息输出到终端时Windows 的 GBK 终端可能直接抛UnicodeEncodeError。解决方案很简单日志输出统一走logging并显式配置errorsreplaceimport sys import logging handler logging.StreamHandler(sys.stdout) handler.setFormatter(logging.Formatter(%(asctime)s %(levelname)s %(message)s)) handler.stream.errors replace # 避免编码异常导致整个日志中断 logger.addHandler(handler)一个编码异常导致整个清理任务崩溃这在长任务里非常难受。加了容错后就算个别日志行变成问号主流程依然能跑完。4.4 Linux 的权限位差异Linux 的/tmp有 sticky bit目录内的文件如果没有写权限可能因属主不同而无法删除。特别是/var/tmp长期运行的服务创建的临时文件可能属于root以普通用户身份清理时会成批失败。我不建议直接在工具里强制提权。更合理的做法是默认以当前用户权限运行遇到权限不足时明确提示哪些文件需要 root 权限建议用 sudo 重新执行一遍但不要自动调用 sudo。这个决策很简单清理工具应该克制损坏数据的概率随着提权操作而上升。当然如果你明确知道这台机器只是你一个人用也可以在打包时固定用 sudo但要谨慎。5. 从脚本到产品化参数、日志、打包与定时清理核心功能跑通只是第一步。一个工具要真正用于日常工作还得解决怎么跟人交互怎么知道它干了什么怎么分发到其他机器这三件事。5.1 CLI 参数设计我最终做成了这样一套命令# 只看会删什么不实际删除 python tmpclean.py --dry-run --older-than 14d # 真正执行并输出日志文件 python tmpclean.py --clean --older-than 7d --log-file /var/log/tmpclean.log # 只清理指定目录 python tmpclean.py --clean --path /home/lucas/.cache/tmp --min-size 1M相关参数解析使用argparse体验很顺import argparse def build_parser(): parser argparse.ArgumentParser(description跨平台临时文件清理工具) parser.add_argument(--dry-run, actionstore_true, help只扫描不删除) parser.add_argument(--clean, actionstore_true, help实际执行清理) parser.add_argument(--older-than, default7d, help文件修改时间超过该值才清理支持 d/h 单位) parser.add_argument(--path, actionappend, help额外指定清理目录可多次传) parser.add_argument(--min-size, default1M, help小于该大小的文件不清理) parser.add_argument(--log-file, help日志输出文件路径) return parser.parse_args()--dry-run我强烈建议保留甚至可以反过来做成默认模式。我在自己电脑上跑了整整两天的 dry-run观察它到底会删什么、统计删多少字节最后确认规则没问题才切换到自动清理。不要一上来就--clean根据我的经验首跑必然出现规则漏洞。5.2 日志与审计清理工具本质上在动用户的文件所以每一步都要有记录。我设计的日志格式是2025-06-14 10:22:31 INFO 扫描根目录: C:\Users\lucas\AppData\Local\Temp 2025-06-14 10:22:32 INFO 删除文件: C:\Users\lucas\AppData\Local\Temp\installer\setup-1624.tmp (12.3MB) 2025-06-14 10:22:33 INFO 目录删除失败: C:\Users\lucas\AppData\Local\Temp\locked-chrome-cache, 原因: 文件被占用 2025-06-14 10:22:40 WARN 以下路径需要手动检查: ...另外我还会输出一份 summary包括扫描文件数、删除文件数、释放空间大小、失败项数方便和同事分享清理战果也让非技术用户知道工具到底干了什么。5.3 PyInstaller 打包与跨平台分发Python 脚本在目标机器上跑需要解释器这算是使用门槛。我用 PyInstaller 做单文件打包pyinstaller --onefile --name tmpclean main.py这里必须强调PyInstaller 只能在哪个系统上打包成哪个系统的可执行文件不能在 Windows 上打包 Linux 版本反之亦然。所以我的发布流程是分别在三台机器上执行一遍Windows 用 GitHub Actions 的 windows runnerLinux 用 ubuntu runnermacOS 用 macos runner。三个平台各出一份二进制再对应发布。打包后有两个小坑单文件模式启动慢。PyInstaller--onefile启动时要先把内嵌的依赖解压到临时目录双击时会有两秒延迟这正常。如果你更在意启动速度可以改用--onedir。杀毒软件误报。第一次打出来的 exe 可能被 Defender 报毒。一个直接原因是 PyInstaller 的引导程序特征明显另一个是确实有恶意软件使用同样的打包方式。我通常会给发布工具做代码签名签名后误报率会大幅降低。5.4 定时清理的落地姿势工具做完后定时清理的需求几乎是立刻涌上来的。我推荐的做法Windows用任务计划程序每天触发一次tmpclean.exe --clean --older-than 14d。Linux写一个 systemd service timer间隔可以设为每周一次。macOS用 launchd plist标记StartCalendarInterval。定时任务的重点是把--older-than调大一点。手动手工跑的时候7 天阈值很舒服但定时任务无人值守一旦误判也许到你发现时数据已经没了。我自己平常设到 21 天宁可不清理不可误清理。这个权衡你跑一段时间也会有感觉。最后再说一个我实际用过的小技巧把这份工具放到一个带--dry-run的定时任务里每天只统计不删除日志自动归档。这样持续跑一个月你对这台机器的临时文件增长速度会有一个非常直观的感知——哪种软件最会堆垃圾、每周各增长多少全都清楚了。有了数据基础再调整清理策略就不会是拍脑袋了。