简介终结者源码是可编译、可定制的远程访问工具RAT源代码定位面向网络安全学习、恶意代码分析与中高级编程开发人群。它覆盖远程桌面查看、命令下发、持久化后门等核心模块也涉及 TCP/IP/HTTP(S) 通信、SSL/TLS 加密、文件系统遍历、权限提升及反检测技巧通过阅读这部分代码能较完整地理解远程控制类软件从连接建立到指令执行的机制同时为防御端的检测与溯源提供参考。资源以 RAR 压缩包发布整包约 3MB文件总数和具体类型明细尚未标注下载后需自行解压、核对目录结构与编译环境若需实际运行建议在隔离虚拟机中配置 GCC、Visual Studio 等工具逐步调试。目前该资源已有 689 人学习适合作为漏洞研究、安全攻防演练、网络编程和反恶意软件课程的延伸材料。1. 项目起源为什么我想写一个“终结者”事情要从上个月说起。当时我在帮一个朋友整理他用了三年的开发电脑发现光是node_modules、__pycache__、.gradle这类缓存文件夹加起来居然占了将近30GB的磁盘空间。一台512GB的MacBook Pro硬盘常年飘红连Xcode都跑不动。我说你怎么忍得住的他说“怕删错东西就一直没敢动”。这种场景其实非常典型。开发者的电脑里充满了各种“运行一次就不会再用”的中间产物——编译缓存、日志文件、临时目录、依赖包副本它们藏在层层嵌套的目录里今天删了明天又生成手动清理效率极低而且极易误删。那一刻我意识到真正值得动手写的工具不是又一个花里胡哨的“系统清理大师”而是一个能精准识别、安全清除“开发垃圾”的命令行小工具。所以我写了这个“终结者源码”项目。它是一个基于Python的批量文件守卫与清理工具核心逻辑并不复杂但对“安全”和“可追溯”的要求特别高。简单说你要终结的不是系统文件而是那些你根本不可能逐个手工清理的缓存和无用产物。这个项目适合谁如果你是Python初学者想找一个能真正“跑起来、看得懂、改得动”的实战项目如果你是被磁盘空间逼疯的开发者如果你想了解如何用一道程序优雅地处理“批量删除”这类高危操作那么这篇博文里的源码和思路应该能给你一个比较满意的参考答案。我把它叫“终结者”是因为它专注做一件事干掉那些不该留存在磁盘上的文件。但它的另一面是每一步删除都先备份、后记录、可撤销。用在生产环境或者自用电脑上都让人比较放心。2. 整体设计思路与方案选型2.1 为什么选Python而不是Shell脚本第一版我考虑过直接用rm -rf配合find命令写一组Shell脚本毕竟Linux/macOS下清理缓存最爽快的方式就是Shell。但很快我就放弃了原因是Shell脚本跨平台能力太差Windows的PowerShell语法和Linux的bash语法不互通而且rm -rf一旦路径写错造成的后果是不可逆的。Python在不同操作系统上行为一致标准库os、shutil、pathlib足够覆盖文件遍历与删除操作而且可以轻松地加入“回收站备份”“操作日志”“大小统计”这些安全机制。对大多数开发者来说维护一个Python脚本的意愿和门槛都远低于维护一套跨平台Shell方案。我用了一个后来认为非常关键的库send2trash。它能把文件移动到系统回收站而不是永久删除。这样即使程序误判了文件类型用户还有后悔药可吃。注意Windows下如果用shutil.rmtree直接删除目录文件不会经过回收站一旦删除就是永久性的。在涉及到批量删除的项目里这属于必须规避的行为。2.2 哪些目录被纳入“该清理”的黑名单我调研了常见开发环境的缓存目录梳理出一个比较保守的基础清单类型路径模式说明Python缓存__pycache__所有Python运行生成字节码的目录Node依赖缓存node_modules/.cachenpm安装依赖后的缓存目录构建产物build、dist、target编译与打包中间产物前端依赖缓存.vite、.parcel-cache现代前端构建工具缓存IDE索引缓存.idea、.vscode/.cache编辑器生成的索引临时文件日志文件*.log运行日志常被轮转或积累临时文件*.tmp、*.temp未正常清理的临时文件系统缩略图缓存Thumbs.dbWindows专用带$前缀的是Windows自身索引清单不是死的项目里提供了可扩展的config.json用户可以根据自己的实际环境增删路径模式。我自己的经验是第一次运行先用“试删除模式”看结果确认无误再执行真实清理这样心理压力会小很多。3. 核心源码细节与应用场景拆解3.1 安全删除的底层机制做一个删除工具第一要务不是“删得快”而是“删得安全”。我封装了一个safe_delete函数它在删除前会先记录文件的完整路径、大小、类型并把文件移动到系统回收站。这个函数的实现不复杂但细节值得展开。import os import time import json from datetime import datetime from pathlib import Path from send2trash import send2trash class FileKiller: def __init__(self, log_filekill_log.json): self.log_file log_file self.deleted_count 0 self.freed_bytes 0 self.log_entries [] def safe_delete(self, path: Path) - bool: 安全删除文件或目录先记录日志再移至回收站。 返回True表示操作成功False表示跳过如路径不存在。 if not path.exists(): return False entry { path: str(path.resolve()), size: self._get_size(path), type: dir if path.is_dir() else file, time: datetime.now().isoformat(), } try: send2trash(str(path)) self.log_entries.append(entry) self.deleted_count 1 self.freed_bytes entry[size] return True except Exception as e: print(f[失败] {path} 删除失败: {e}) return False def _get_size(self, path: Path) - int: if path.is_file(): return path.stat().st_size total 0 for root, dirs, files in os.walk(path): for name in files: try: total os.path.getsize(Path(root) / name) except OSError: pass return total其中_get_size方法在计算目录大小时用了os.walk遍历这本是一个比较耗时的操作。我实测发现在一个包含十万个文件的node_modules目录上计算体积大约需要3到5秒——这个延迟在交互式工具里可以接受所以没有引入更复杂的并行计算方案。日志写入部分用JSON格式存储每次运行结束生成独立的kill_log_timestamp.json文件方便用户按时间回查。这一点在后来的使用中帮了大忙有一次工具误把某个项目的build目录当成构建缓存删掉了用户通过日志轻松找到原始路径并从回收站恢复了文件。3.2 配置驱动的目标库设计硬编码路径是一个大坑。第一版我把路径直接写在代码里后来别人拿去用的时候发现自己项目的缓存目录根本不在清单里。所以我很快重构为“配置驱动”使用config.json作为黑名单规则源代码里只需要读配置、做匹配。{ targets: { cache_dirs: [ node_modules/.cache, __pycache__, .pytest_cache, .mypy_cache, target, build, dist ], file_patterns: [ *.log, *.tmp, *.temp, Thumbs.db, .DS_Store ], older_than_days: 7 }, scan_paths: [ { path: /home/user/projects, recursive: true, exclude: [node_modules, .git] } ] }解析这个配置的代码里有一个容易踩坑的点exclude列表中的目录如node_modules、.git本身可能包含大量文件如果扫描时没有排除效率会急剧下降。我在遍历时做了两级过滤def scan_for_targets(scan_path: Path, config: dict) - list[Path]: 根据配置扫描需要清理的目标路径 candidates [] exclude_dirs set(config.get(exclude, [])) dir_patterns config[targets][cache_dirs] file_patterns config[targets][file_patterns] for root, dirs, files in os.walk(scan_path): # 修改dirs列表以剪枝排除目录 dirs[:] [d for d in dirs if d not in exclude_dirs] for d in dirs: full_dir Path(root) / d if d in dir_patterns: candidates.append(full_dir) for f in files: if any(f.endswith(pattern.replace(*, )) for pattern in file_patterns): candidates.append(Path(root) / f) return candidates这里有一个比较实用的细节dirs[:] ...是对os.walk原地剪枝如果不这样做os.walk仍然会递归进入node_modules的每一层白白浪费IO。实测在大规模项目目录树上这一行修改能将扫描时间从几十秒压缩到几秒。3.3 试删除与真实删除的双模式运行我强烈建议任何写删除工具的人都加上“试运行”模式。这个模式不是简单地打印“我找到了N个文件”而是要精确地展示“如果执行清理会删除哪些文件、释放多少空间、涉及哪些目录”。我的实现如下def run_cleanup(mode: str dry) - None: mode: dry 表示试运行只统计不删除 real 表示真实清理 killer FileKiller() config load_config(config.json) all_candidates [] for scan_path_conf in config[scan_paths]: scan_path Path(scan_path_conf[path]) candidates scan_for_targets(scan_path, config) if mode dry: for candidate in candidates: size killer._get_size(candidate) all_candidates.append((candidate, size)) else: killer.safe_delete(candidate) if mode dry: total_size sum(size for _, size in all_candidates) print(f[试运行] 发现 {len(all_candidates)} 个目标) print(f[试运行] 预计释放空间: {format_size(total_size)}) print(---- 前20条明细 ----) for path, size in sorted(all_candidates, keylambda x: -x[1])[:20]: print(f{format_size(size):8} {path})第一次使用工具时请务必先用--dry方式运行。我自己的习惯是至少试运行两次第二次检查输出结果里有没有自己写过代码的目录——如果出现了说明过滤规则太激进需要调整配置。这一步虽然简单但能免除大部分“误删事故”。3.4 通过argparse让工具具备命令行可用性判断一个工具“好用”还是“能用”命令行接口设计是很重要的一环。我用了Python标准库的argparse来构建参数解析支持--modedry/real、--config指定配置文件、--verbose打印详细日志三个核心参数。import argparse def parse_args(): parser argparse.ArgumentParser( description终结者源码一个安全的开发缓存清理工具 ) parser.add_argument( --mode, choices[dry, real], defaultdry, help运行模式dry表示试运行real表示真实清理, ) parser.add_argument( --config, typestr, defaultconfig.json, help配置文件路径默认使用当前目录下的config.json, ) parser.add_argument( --verbose, actionstore_true, help输出详细日志信息, ) return parser.parse_args()这样设计的好处是工具可以无缝接入定时任务或者Git钩子。比如你可以在pre-commit钩子里加一行python terminator.py --mode dry --config .terminator/config.json每次提交代码前先看看到底有多少垃圾缓存会被清理。这种用法在实际开发中非常受用等于让“终结者”成了项目仓库的一名隐形巡检员。4. 实操过程从克隆到跑起来的完整记录4.1 准备阶段与依赖安装先说运行环境。我在macOS 13、Ubuntu 22.04、Windows 11三个平台各跑了一遍都没有遇到无法解决的问题。Python版本建议3.9以上主要依赖只有send2trash和colorama用于终端彩色输出不是必需但体验更好。# 克隆项目并进入目录 git clone https://github.com/yourname/terminator-source.git cd terminator-source # 创建虚拟环境强烈建议避免污染全局Python环境 python3 -m venv venv source venv/bin/activate # Windows下为 venv\Scripts\activate # 安装依赖 pip install -r requirements.txt # 查看帮助 python terminator.py --helprequirements.txt内容非常简单只有两行send2trash1.8.3 colorama0.4.64.2 首次试运行观察清单输出初始配置里的scan_paths默认指向/home/user/projects如果你和我一样把项目放在其他路径下需要先编辑config.json。我建议第一次运行时把扫描路径指向一个小范围目录例如只有一个项目、不包含重要文件的测试目录。python terminator.py --mode dry --verbose我在一台有3个Node项目和5个Python项目的开发机上执行后输出结果大致如下[试运行] 发现 27 个目标 [试运行] 预计释放空间: 1.24 GB ---- 前20条明细 ---- 820.5 MB /home/dev/projects/store-frontend/node_modules/.cache 210.2 MB /home/dev/projects/admin-panel/node_modules/.cache 86.1 MB /home/dev/projects/store-frontend/dist 61.3 MB /home/dev/projects/api-service/__pycache__ ...这里要注意的是node_modules/.cache往往是最大头但不能轻易删掉node_modules本身因为那是项目运行所需依赖删了就要重新npm install耗时极长。之所以只匹配node_modules/.cache这个二级目录就是基于这个经验教训。4.3 检查明细后执行真实清理试运行输出确认无误后切换到真实模式python terminator.py --mode real --verbose真实模式会调用safe_delete把每个文件都送入回收站因此执行时间会比试运行长不少。我做了一个粗略的基准测试在包含约6万个目标文件的扫描结果上执行真实删除耗时约3分20秒主要瓶颈在于send2trash跨磁盘移动文件到回收站的速度。如果你清理的量特别大建议分段执行不要一次塞太多否则回收站会瞬间膨胀反倒增加后续手动整理负担。执行完毕后程序会在当前目录生成类似kill_log_20250616_143500.json的日志文件。我在实际使用中养成了一个习惯每次真实清理后都会打开日志文件用grep快速检索一遍有没有“看着不对劲”的路径确认无误后才算本次清理真正结束。5. 常见问题与排查技巧实录5.1 误删了重要文件怎么办这是最让人紧张的场景但实际上由于send2trash的存在绝大多数误删是可逆的。操作方法很简单打开系统回收站找到对应的文件或目录右键还原即可。Windows下回收站还能按“删除日期”排序你可以根据日志文件里记录的时间精确找到那批文件。macOS则在废纸篓里按名称搜索。提示如果你之前手工用过shutil.rmtree版本那文件没法恢复。这也是我一直强调能用send2trash就不要用rmtree的原因。绝对不要在代码里直接shutil.rmtree除非你确信那个目录毫无价值。5.2 清理后某个项目无法正常运行这个问题的常见原因是dist或target目录被误删了。如果项目还在开发阶段只需重新构建即可# 前端项目 npm run build # Java项目 mvn clean package # Python项目 python setup.py build如果项目已经部署在生产环境且依赖构建产物运行那问题就严重了。所以我在设计规则时把dist和target默认放在“需要显式开启才会清理”的扩展规则里核心配置文件默认只清理缓存和日志类。5.3 为什么扫描速度特别慢从经验看慢的根源基本是遍历了不该遍历的目录比如.git、node_modules、venv。这些目录里有海量小文件os.walk会在它们身上花掉80%以上的时间。解决方法是确保exclude里显式列出这些目录。此外还可以考虑用pathlib的rglob替代os.walk——在某些场景下更优雅但底层性能差距不大主要优化点还是“剪枝”。5.4 规则误匹配到非缓存文件怎么办例如有些项目里真的有一个叫build的源码目录比如存放构建脚本的目录被默认识别为构建产物。这种情况的处理方式是在scan_paths.exclude里添加具体路径或者在config.json中新增一个whitelist字段{ whitelist: [ /home/dev/projects/my-tool/build ] }代码中扫描到候选目标后先检查是否命中白名单命中则跳过。这个字段虽然很简单但在实际使用中能省去很多沟通成本特别是当你把工具分享给同事使用时他们可以不改代码、只改配置就能适配自己的项目结构。5.5 如何扩展自己的清理规则我鼓励使用者在项目中沉淀自己的“垃圾文件黑名单”。比如我个人的配置里增加了*.pyc、.ipynb_checkpoints、.DS_Store等模式做前端时还会加上.eslintcache。此外还有一些“低频但有用”的规则比如node_modules目录下超过6个月的*.tgz压缩包可以安全删除——这些通常是npm缓存历史包实际上再也用不到。这类规则需要用到older_than_days参数我把它加进配置后工具会自动判断文件修改时间过期才处理。6. 一些小而有价值的扩展方向这个项目如果继续演进我目前觉得有三个方向特别值得做。第一是接入cron或系统计划任务每周自动执行一次dry模式巡检把报告通过邮件或钉钉机器人推送到邮箱/群里。这样能保持“清理不主动、但时不我待”的维护节奏不用总想着手动跑一次。第二是做成一个Tkinter或Web界面。后端逻辑已经完全和UI解耦只需要把scan_for_targets和safe_delete暴露成接口再用Flask包一层HTTP API就能让不懂命令行的同事也能轻松操作。第三是增加“文件类型聚合统计”能力。目前_get_size只能返回总大小无法知道“到底哪类文件占空间最大”。我准备加一个按扩展名聚合的统计函数让用户在清理前先看到一张“胖文件榜”就能反向推动他们去关注项目中不合理的依赖或资源。7. 写在最后的几点真相维护这个项目至今我最大的感悟是清理工具最大的敌人不是垃圾文件而是使用者的恐惧和疏忽。恐惧来源于不透明所以这个工具花了大量篇幅在日志、试运行、白名单这些“额外动作”上疏忽来源于不自动化所以最终的答案不是“每天手动跑一次”而是“通过配置和定时任务让它成为开发环境里无声的守护者”。我自己现在每周五下班前会固定跑一次--mode dry看到磁盘空间蹭蹭往上涨的时候心里反而特别踏实——因为我知道它们都能被安全回收。如果有机会用到这个思路的读者我建议你动手改出自己的版本加一个你想清理的场景、删一个你不需要的规则、换一种你更舒服的日志格式。工具是死的但你在改造它的过程中获得的思考才是这个项目真正的价值所在。本文还有配套的精品资源点击获取