
说实话我第一次卸 OpenClaw就是大家常叫的“龙虾”的时候以为跑一句npm uninstall -g openclaw就完事了。结果过了两周某台机器的终端配置里还躺着它的环境变量WSL 里还蹲着一个旧版实例Windows 那边连 Companion 的托盘进程都还活着。这次经历让我彻底明白卸载一个现代命令行工具从来不是“删掉主程序”这么简单。OpenClaw 可能通过 npm 全局包、源码目录、WSL 子系统、Windows Companion 四种方式分别留下痕迹任何一条漏掉都会在你下次打开终端或者重启服务时猝不及防地跳出来。这篇文章就把我从命令行到残留清理的完整排查链路写出来。不管你是装完试了两天就想删的新手还是部署了 skill、配过记忆库、改过环境变量的进阶用户都能按图索骥一次卸干净别像我一样返工。1. 卸载前先摸清安装方式三种常见路径的区别很多人上来就执行卸载命令结果要么提示“找不到包”要么删了主程序但配置文件还在最尴尬的是删到一半才发现自己根本不记得当初是怎么装的了。所以第一步不是动手删而是花三分钟搞清楚 OpenClaw 到底以什么形式存在于你的系统里。1.1 判别方法命令、目录、包管理器三管齐下先做最基础的定位。打开终端依次执行下面几条命令把输出记下来# 查看可执行文件的实际路径macOS/Linux which openclaw # Windows PowerShell Get-Command openclaw | Select-Object Source # 查看 npm 全局包列表里有没有它 npm ls -g --depth0 | grep openclaw # Windows 下没有 grep 就用 npm ls -g --depth0 | findstr openclaw # 看看是不是通过 Homebrew 装的 brew list | grep openclaw这一步的输出能直接告诉你第一重身份。如果which openclaw返回的路径在/usr/local/bin或者 npm 的全局 bin 目录下基本可以确定是 npm 全局安装如果路径指向某个你手动 clone 的目录比如~/projects/openclaw那就是源码部署如果命令根本找不到但你在终端里明明能用多半是 WSL 内部安装或者 Windows Companion 的可执行文件路径被加进了 PATH。1.2 区分 npm 全局安装与源码部署的影响范围这两种安装方式最大的区别在于npm 全局包的文件分散在 node_modules 和全局 bin 目录里删除后还需要确认没有别的项目依赖它而源码部署通常把代码、配置、数据都集中在同一个目录下看起来好删但风险反而是数据目录和配置目录可能散落到用户目录的其他位置。我自己见过最典型的翻车场景有人从 GitHub 上 clone 了一份 OpenClaw 源码放在~/dev/lobster运行时它会在~/.config/openclaw/和~/.local/share/openclaw/下写入配置和数据。后来他直接rm -rf ~/dev/lobster以为删干净了其实~/.config里的 skill 配置和对话历史原封不动地躺在那里。所以卸载前一定要把“程序主目录”和“配置数据目录”分开来看。1.3 WSL 场景的特殊判别先看发行版状态如果你是在 Windows 上用 WSL 跑 OpenClaw情况又复杂一层。热词里那句“OpenClaw 无法安全验证 SL2 环境。请在 PowerShell 中运行 wsl -- status”我见过很多次这是典型的 WSL 版本或发行版状态异常导致的报错。卸载前先在 PowerShell 里跑一下wsl --status wsl --list --verbose输出会告诉你当前默认版本是 WSL 1 还是 WSL 2以及你装了几个发行版、分别是 Running 还是 Stopped 状态。如果 OpenClaw 是装在某个发行版内部的那你要处理的对象不是 Windows 应用而是那个发行版环境——要么进入发行版内部卸载要么直接把整个发行版注销。两种做法的后果差异很大后面我会专门展开。1.4 别忘了 Windows Companion 这种“看起来不像命令行”的安装很多开源工具为了让普通用户能用起来会额外提供一个桌面伴侣程序。OpenClaw 的 Windows Companion 就是这种角色。它本身可能是一个独立安装包也可能只是把 Node.js 服务和托盘图标绑定在一起。你在命令行里搜不到它的身影但它在任务栏右下角、启动管理器里都占着位置。所以判别安装方式时别只盯着终端还要去“设置—应用”里搜一下 openclaw 相关条目同时打开任务管理器看一下有没有相关后台进程。2. 命令行卸载主流程四类安装场景的分路操作确定好安装方式之后就可以各走各的卸载路径了。下面是四类最常见场景的完整命令和操作细节每一步我都会解释为什么这么做而不是只丢给你一条命令。2.1 npm 全局包的标准卸载与权限坑这是最简单也最容易出幺蛾子的一类。标准命令只有一条npm uninstall -g openclaw但这里有个非常典型的坑如果你当初安装时用了sudo那么卸载时大概率也需要sudo否则你会看到一堆EACCES: permission denied的报错。我见过太多人卡在这一步然后就误以为“卸不掉”。其实正确的做法是保持安装时的权限一致性# 如果之前用 sudo 安装卸载也用 sudo sudo npm uninstall -g openclaw另外一个细节是如果你用的是 pnpm 或 yarn 这类替代包管理器不要混用。用 pnpm 安装的全局包npm 是删不掉的。先确认到底是哪个包管理器装的pnpm ls -g | grep openclaw yarn global list | grep openclaw确认之后再对应用pnpm uninstall -g openclaw或yarn global remove openclaw来卸载。这一步容易被忽略因为命令行里输入openclaw能跑大家就默认是 npm 装的实际上底层的符号链接可能来自 pnpm 的全局仓库混用包管理器会导致删完 npm 侧的数据后命令依然能执行。卸载完成后不要急着走顺手把全局目录里的符号链接确认一下# 查看 openclaw 命令是否还存在 which openclaw如果提示not found说明主程序已经摘干净了。2.2 源码部署目录的处理停进程、删目录、查数据三连击源码部署卸起来步骤多一些。核心逻辑有三步先把正在跑的进程停下来再把代码目录删掉最后去查它运行时写出去的数据。第一步停进程。很多人直接删目录结果进程还占着端口过一会儿目录又自己冒出来甚至报“Text file busy”。正确做法是# 找到 openclaw 相关进程 ps aux | grep openclaw # 或者 Windows 下用 tasklist 和 taskkill tasklist | findstr openclaw拿到 PID 之后用kill -9 PID或者taskkill /PID PID /F强制结束。第二步删目录。把当初 clone 或者解压出来的主目录整个删掉。如果你不记得目录在哪可以回到 1.1 节用which openclaw溯源顺着符号链接找到真实路径再往上回退到项目根目录。第三步也是最重要的一步查数据。源码部署的 OpenClaw 几乎一定会往用户目录写入配置和数据常见位置包括~/.openclaw/~/.config/openclaw/~/.local/share/openclaw/~/.cache/openclaw/这些目录不会因为主程序删除而自动消失。删不删取决于你的需求如果只是不想用这个工具了我建议把配置和数据一起清掉真正做到“干净卸载”如果以后可能还会装回来可以把整个~/.openclaw目录打包备份而不是直接删空。2.3 WSL 内部的卸载进子系统删还是直接注销发行版二选一的决策WSL 场景是 OpenClaw 卸载里最需要谨慎的。你要先想清楚一个问题OpenClaw 是装在一个独立的发行版里还是和你日常使用的 Ubuntu/Debian 混在一起。如果是混在常用发行版里那就不能把发行版整个注销而是进入 WSL 环境内部按 Linux 的方式卸载。假设你在 WSL 的 Ubuntu 里用 npm 装的# 先进入 WSL wsl # 然后在 WSL 内部执行 npm uninstall -g openclaw rm -rf ~/.openclaw ~/.config/openclaw如果你当初是为了跑 OpenClaw 专门装了一个发行版或者发现这个发行版里几乎没有其他用途那直接注销整个发行版更省事。方法是在 PowerShell 里执行# 先看发行版列表和名称 wsl --list --verbose # 注销指定发行版注意大小写和名称要完全一致 wsl --unregister DistroName这个命令会把整个发行版的文件系统删除包括里面所有数据执行前系统也会给你警告。如果你在乎里面的任何数据先备份再注销。注销之后再用wsl --list --verbose确认列表里已经空了。这里要特别解释热词里提到的那个场景——“OpenClaw 无法安全验证 SL2 环境请在 PowerShell 中运行 wsl -- status”。我遇到过用户反馈OpenClaw 装好后提示 WSL 环境验证失败结果他以为是 OpenClaw 有问题跑去重装 WSL最后才发现是系统里存在多个发行版OpenClaw 的启动脚本检测到的默认版本不是它运行所需要的那个。类似这种报错卸载时也可能复现。遇到这种情况优先处理 WSL 本身的版本一致性再谈卸载 OpenClaw否则你即使卸了 OpenClawWSL 里的残留环境依然可能干扰其他工具。2.4 macOS 与 Homebrew 场景的补充说明如果你是在 macOS 上通过 Homebrew 安装的 OpenClaw卸载就多一条分支brew uninstall openclaw但 Homebrew 卸载后同样会残留缓存。你可以顺手用brew cleanup清掉旧的下载缓存再手动检查/usr/local/Caskroom如果当初是通过brew install --cask装的里有没有对应的应用残留。另外 macOS 下很多人的 shell 是 zshPATH 配置写在了~/.zshrc里后面清理环境变量时要注意这个差异。3. 残留清理配置目录、缓存、环境变量与 PATH 的全面排查主程序卸完之后真正的重头戏才开始。OpenClaw 这种带 skill 机制、记忆库和配置系统的工具运行时会在系统里埋下不少“地雷”一个不拆将来轻则占用磁盘重则导致其他命令行工具的行为异常。3.1 配置文件到底散落在哪按平台逐一排查先给出一份按操作系统的排查清单你可以照着逐个检查平台配置目录数据目录缓存目录Linux~/.config/openclaw/~/.local/share/openclaw/~/.cache/openclaw/macOS~/Library/Application Support/openclaw/~/Library/Application Support/openclaw/~/Library/Caches/openclaw/Windows%APPDATA%\openclaw\%APPDATA%\openclaw\%LOCALAPPDATA%\openclaw\这份清单是基于大多数 Node.js 命令行工具遵循的目录规范推断的具体到你机器上可能名称稍有出入但搜索方法是一致的。在 Linux/macOS 上可以用一条命令快速摸清所有相关目录find ~ -maxdepth 4 -iname *openclaw* 2/dev/nullWindows 上则推荐用 PowerShellGet-ChildItem -Path $env:USERPROFILE -Recurse -Depth 3 -Filter *openclaw* -ErrorAction SilentlyContinue | Select-Object FullName搜索出来的结果你要区分哪些是必须删的配置哪些是日志和缓存。配置目录里面通常有config.yaml、skills/、memory/之类的结构缓存目录里则多半是临时文件、日志、模型调用的中间产物。我的原则是配置和数据目录按需备份或删除缓存目录直接删掉不需要任何心理负担。3.2 环境变量和 PATH删不干净的隐形残留很多人在卸载后遇到“明明卸了终端一打开还是会加载 OpenClaw 相关的东西”或者“提示找不到 openclaw 命令但某条 PATH 里还有它的路径”问题就出在环境变量上。你需要检查以下几类位置Shell 配置文件~/.bashrc、~/.zshrc、~/.profile、~/.config/fish/config.fish系统级 PATHmacOS 的/etc/paths和/etc/launchd.confWindows 的“系统环境变量”启动脚本Linux 的~/.bash_profilemacOS 的~/Library/LaunchAgents/下的 plist 文件Windows 的“启动”文件夹和注册表 Run 键排查方法很简单用搜索命令把这些文件里包含 openclaw 或相关路径的行找出来# Linux/macOS grep -n -i openclaw\|lobster ~/.bashrc ~/.zshrc ~/.profile ~/.bash_profile 2/dev/null # Windows PowerShell Select-String -Path $env:USERPROFILE\.bashrc,$env:USERPROFILE\.zshrc -Pattern openclaw -SimpleMatch找到之后手动删除对应的export PATH...openclaw...或alias openclaw...行。这里有个容易手滑的坑如果你只是删除了命令但没有删掉导出 PATH 的那一行终端启动时不会报错但每次打开新终端都会多一次“查找不存在的路径”的无效操作积少成多终端的启动速度会明显变慢。Windows 用户还需要额外检查一下 PowerShell 的 profile 文件可能藏在$PROFILE这个路径因人而异但通常位于Documents\WindowsPowerShell\或Documents\PowerShell\下。打开之后搜索 openclaw删掉相关初始化代码。3.3 开机自启任务和系统服务的清理OpenClaw 这类常驻型工具安装时很可能顺手注册了自启任务。卸载主程序后如果你的系统每次开机依然会尝试拉起某个 openclaw 后台进程或者某个端口还是被占用问题就出在自启项上。按平台排查Linux (systemd)systemctl --user list-unit-files | grep openclaw有输出就执行systemctl --user disable openclaw.service并删除对应的 service 文件。macOS (LaunchAgent)检查~/Library/LaunchAgents/下面有没有com.openclaw.plist之类的文件有就launchctl unload之后直接rm。Windows (任务计划程序)在“任务计划程序”里搜索 openclaw同时按下Win R输入shell:startup查看启动文件夹。这一块很多人会漏掉但它恰恰是“卸了还复蹦”的头号根源。尤其是 Windows 上有些工具会注册一个“在用户登录时运行”的任务你删了程序文件任务计划还指向原路径虽然会报错但进程管理列表里看起来依然有 openclaw 的踪迹很容易造成“根本没卸干净”的错觉。3.4 浏览器扩展和其他联动物最后再扫一遍如果你在浏览器里装过 OpenClaw 配套的扩展比如用于唤起本地命令行的工具需要在浏览器扩展管理页把它禁用一个一个移除。同时检查一下 IDE 或终端软件里是否配置了与 OpenClaw 集成的插件或快捷键。具体表现为你在 VS Code 的命令面板里还能搜到 openclaw 相关命令或者终端美化工具比如 Starship、Oh My Zsh的配置里还有一行command openclaw --version。这类联动的残留不影响系统稳定性但会影响使用体感。每次打开终端你都会看到一行红色提示“command not found: openclaw”非常烦人。解决方式就是沿着配置文件的引用关系往回找把对应的配置项删掉。4. WSL 集成与 Windows Companion最容易漏掉的两个角落前文提到过这两个入口但它们的坑实在太典型值得单独拿出来展开讲。如果你在 Windows 上用过 OpenClaw我强烈建议你把这一节看完。4.1 WSL 环境残留的判定方法很多人在 Windows 上卸载了所有可见的 OpenClaw 程序后却发现wsl --status的输出依然异常或者某个端口被未知进程占用这时最可能的原因就是 WSL 内部还有一套 OpenClaw 环境。判定方法很简单# 查看所有 WSL 发行版 wsl --list --verbose # 进入疑似装有 OpenClaw 的发行版检查 wsl -d DistroName -- which openclaw如果which openclaw输出了一个路径说明这个发行版内部确实装了 OpenClaw。接下来你要决定是只删内部包还是注销整个发行版。我在 2.3 节已经给过两种做法的详细命令这里补充一个决策标准如果你平时还会用这个 WSL 发行版跑其他开发任务就进入内部卸载如果这个发行版是当初为了跑 OpenClaw 专门装的里面已经没什么值得保留的数据了就直接注销。注销这件事本身也能顺便清理掉很多 Windows 和 WSL 之间的关联配置。4.2 wsl --unregister 背后的驱动器和数据影响wsl --unregister这个命令很强大它会把整个发行版的虚拟磁盘文件通常是一个.vhdx文件连同内部所有文件系统数据删除。所以执行前你需要知道三件事你的.vhdx文件占了多大空间删除后会被释放。发行版内部有没有你还没备份的数据。卸载后是否会影响 Docker Desktop 或其他依赖 WSL 的工具。我建议任何人在注销之前先跑一次wsl --export到外部磁盘哪怕是临时的安全备份wsl --export DistroName D:\backup\distro.tar注销之后如果后悔了还能用wsl --import恢复回来。这个操作成本很低但能在关键时刻救命。另外卸载 OpenClaw 不一定非要注销整个发行版。如果当初只是在一个通用发行版里通过 npm 装的那npm uninstall -g openclaw rm -rf ~/.openclaw ~/.config/openclaw ~/.cache/openclaw就足够了完全没必要动发行版本身。别把“彻底卸载”理解成“要把与之相关的所有东西全部暴力删除”精准打击才是效率最高的。4.3 Windows Companion 的卸载路径与隐藏组件Windows Companion 这类伴生程序它的卸载入口通常隐藏在“设置—应用—已安装的应用”里搜索 openclaw 就能看到。点卸载后程序主体会消失但有几类东西它会悄悄留下当前用户目录下的.openclaw配置文件夹如果 Companion 和命令行工具共用配置目录注册表里HKCU\Software\OpenClaw相关的键任务计划程序里名为 OpenClaw Updater 之类的更新任务防火墙规则里指向 OpenClaw 的入站/出站规则前两类按照第 3 节的方法清理即可。注册表项可以用regedit手动搜索删除但操作前一定要先备份注册表或者至少导出对应分支。防火墙规则可以在“高级安全 Windows Defender 防火墙”里找到后右键删除。一个比较冷门但真实存在的情况Companion 可能会把自己的数据写到%PROGRAMDATA%\OpenClaw\系统级 ProgramData这个位置默认隐藏普通用户根本不会去看。删除时如果权限不足可能需要管理员权限路径是C:\ProgramData\OpenClaw。在资源管理器地址栏直接输入这个路径能进去就说明还在删掉它不然下次装新版 OpenClaw它连配置和登录状态都能给你保留下来说不定还会和你新装的版本起冲突。4.4 与终端和 IDE 的关联配置Git Bash、VS Code、Windows Terminal 的场景最后提醒一个非常容易被忽略的角落如果 OpenClaw 为 Windows Terminal 或 VS Code 添加过自定义配置比如自定义 profile、集成终端的 shell 路径你卸载后打开 Windows Terminal 的下拉菜单可能还能看到一个名为“OpenClaw”的独立标签页配置。清理方法是打开 Windows Terminal 的设置 JSON 文件搜索 openclaw把对应的 profile 配置块删掉。VS Code 的话在settings.json里搜索 openclaw 路径把相关的终端配置项一并清掉。5. 验证卸载是否彻底三条命令、两个目录、一个端口很多人卸载完就以为大功告成直到某天需要排查问题时才被残留文件打脸。我习惯在卸载完成后做一套标准验证流程全部通过才算真正结束。这套流程总共分五步每一步都对应一类最容易被遗漏的残留。5.1 第一步命令层级验证回到终端执行# 检查 openclaw 是否还能被找到 which openclaw # Windows PowerShell 用 Get-Command openclaw # 直接尝试执行 openclaw --version如果输出是command not found或者无法将“openclaw”项识别为 cmdlet、函数、脚本文件或可运行程序的名称第一层通过。这里我额外加一条如果你的 shell 之前加载过 openclaw 的补全脚本很多工具安装时会往~/.bash_completion.d/或 zsh 的compinit里塞补全文件删除后补全系统里可能仍然缓存着旧命令。验证方法就是打开一个新的终端标签页输入openclaw再按两下 Tab如果没有任何补全提示说明干净了。如果没有就得去.bash_completion.d/或 zsh 的补全目录里把 openclaw 相关文件删掉。5.2 第二步目录层级验证按第 3.1 节的清单逐一访问这些路径~/.openclaw或~/.config/openclaw~/.local/share/openclaw或~/Library/Application Support/openclaw~/.cache/openclaw或%LOCALAPPDATA%\openclaw%APPDATA%\openclaw在文件管理器地址栏直接输入这些路径如果提示“找不到路径”或目录不存在第二层通过。如果目录还在但里面是空的说明残留了空壳目录顺手删掉即可。5.3 第三步进程与端口验证OpenClaw 拉起的后台服务通常会监听某个本地端口。虽然具体端口号可能因配置而异但你可以用一个通用方案来排查# Linux/macOS lsof -i :端口号 2/dev/null # 或者直接搜索进程 ps aux | grep -i openclaw # Windows netstat -ano | findstr :端口号 tasklist | findstr -i openclaw如果没有任何进程和端口占用第三层通过。如果你不确定 OpenClaw 用的是什么端口可以观察netstat -ano | findstr LISTENING的输出里有没有陌生的本地地址结合进程名判断。5.4 第四步自启项与计划任务验证这一步针对 3.3 节的清理做复检Linuxsystemctl --user list-unit-files | grep openclaw输出为空macOSls ~/Library/LaunchAgents | grep openclaw输出为空Windows任务计划程序里搜索 openclaw 无结果“启动”文件夹里也没有相关快捷方式全部为空第四层通过。5.5 第五步注册表与配置引用验证Windows 专项Windows 用户最后在注册表里搜一遍 openclawreg query HKCU\Software /f openclaw /s reg query HKLM\Software /f openclaw /s如果提示“找不到”说明注册表层面的残留也清理干净了。这一项对通过 Companion 安装过 OpenClaw 的机器特别重要因为部分版本会把已安装路径写到注册表的 App Paths 键里这个键不清掉你在“运行”对话框里输入 openclaw 依然可能会触发错误弹窗。五步走完这台机器才算真正和 OpenClaw 撇清关系。这个验证流程看起来繁琐但顶多花五分钟能帮你省掉后续无数“奇怪的报错”排查时间。6. 我踩过的坑权限、误删数据、清理过度最后分享几个我在实际卸载过程中踩过的坑希望你别在同一个地方跌倒。这里没有大道理全是真实操作的教训。6.1 第一个坑sudo 安装的包普通权限卸载我第一次卸载 npm 全局包时直接敲了npm uninstall -g openclaw刷了满屏的EACCES错误。当时以为是包损坏还跑去重装了 Node.js。后来才反应过来安装时用了sudo卸载也必须用sudo。记住一句话安装时的权限等级就是卸载时的权限等级。另外用sudo npm本身就是个不太好的习惯很容易污染全局目录的归属权限。如果你已经这么干了卸载后顺手chown -R $(whoami) /usr/local/lib/node_modules /usr/local/bin把目录归属改回来不然以后装别的全局包还会遇到权限问题。6.2 第二个坑把配置目录当缓存目录一把梭清理残留时我把~/.config/openclaw整个删了当时想着反正不用了全删干净。结果后来项目需要提取之前的对话历史和 skill 配置时才发现没了。其实配置目录里的数据并不是一堆垃圾有些是你投入过时间调出来的东西。现在我的原则是清理前先看一眼目录大小和内容结构凡是和“学习痕迹”相关的比如skills/、memory/、agents/全部先打包备份放到一个固定的 backup 目录里确认三个月内用不到再删。备份的命令很简单tar -czf openclaw-backup.tar.gz ~/.openclaw ~/.config/openclaw磁盘上多一个几百 MB 的压缩包远好过失去不可再生的数据。6.3 第三个坑清理过度误删了共享的 Node 模块有一次我为了“彻底卸载”手动去node_modules目录里把所有带 openclaw 字样的文件夹都删了结果顺手删掉了一个被其他工具共同依赖的公共模块。第二天另一个 CLI 工具直接跑不起来那个报错让我排查了一个下午。所以我的建议是不要让手动删除成为第一选择能用npm uninstall这类标准流程就用标准流程。标准卸载命令比手动rm -rf聪明得多它会处理依赖关系和全局软链不会伤及无辜。6.4 第四个坑卸载后命令还在的原因——Shell 哈希缓存删完主程序后我打开终端执行openclaw居然还能找到命令。当时一度以为没删干净反复检查了好几遍。后来才明白shell 会把命令路径缓存到哈希表里尤其是 zsh 和 bash。解决办法很简单跑一下hash -r或者直接关闭当前终端重新开一个哈希缓存就会刷新。如果你用的是现代终端工具比如 Windows Terminal 或 Warp它们为了加快启动速度会预存一批命令路径这个缓存要稍微等一会儿或者重启终端才能刷新。6.5 第五个坑Windows 上卸载工具和注册表清理的顺序如果你在 Windows 上用了第三方卸载工具比如各种“卸载大师”或wintoolbox这类工具来清理 OpenClaw我的建议是先手动用官方卸载入口卸掉 Companion再用卸载工具扫描残留最后手动清理注册表。顺序反过来的话卸载工具可能会把主程序强制删除但注册表里的卸载入口信息还留着下次在“应用”列表里看到一条已经打不开的卸载项强迫症直接被逼疯。写在最后一次卸载的完整时间线回顾整篇文章一次合格的 OpenClaw 卸载应该包括这样的时间线先在终端里摸清安装方式再按对应的 npm、源码、WSL 或 Companion 路径分别卸载主程序然后清理配置、缓存、环境变量和自启项最后用命令、目录、进程、自启项四类验证手段确认清理结果。整个过程熟练的话十五分钟能搞定不熟练也别急按步骤来每一步的输出和判断我都写清楚了。我个人现在的习惯是无论装什么新工具都会先在终端里跑一次which确认安装方式然后在笔记里记下安装日期和方式。这样将来卸载的时候不用再来一次“全系统大搜索”。这个习惯帮我省下来的时间远比当初记录那两分钟多得多。