磁盘快满了，你发现某个工具在硬盘上留了好几个版本目录，于是想清理掉旧的那些。判断哪个是旧的，你的依据是——版本号。这看起来很合理，直到你意识到：正在被你使用、支撑着当前这个会话的那个版本，可能不是你"按版本号以为的"那一个。
现象
- 某个常用工具（比如命令行工具、编辑器、运行时）在磁盘上有多份版本目录；
- 老板本占用着可观的空间，看着就是"可以删的"；
- 按版本号从低到高排一遍，准备把低的删掉；
- 删之前随手确认了一下，结果发现当前正在运行的程序，路径指向的根本不是版本目录里的那个文件。
如果当时真的动手删了，就会直接破坏正在使用中的环境——而且因为是"正在运行"，报错可能延迟到下次启动才发作。
根因
根因是：版本号 ≠ 当前实际运行的可执行文件。
现代工具（尤其是会自我更新、支持多版本的）往往不是简单地"一个版本一个目录、命令指向最新那个"。常见的几种结构都会让"按版本号猜"失效：
- 命令指向的是一个独立的入口文件，它自己去决定该调哪个版本。这个入口文件和版本目录里的文件是两个独立文件——既不是硬链接，也不是符号链接。你删版本目录，不影响它；反过来，你以为在用的那个版本，可能压根不是它。
- 更新后旧版本不会自动清理，于是磁盘上留下一堆"看起来是旧的"，其中一个可能是"某个组件还在引用它"。
- 有的版本目录被装在别的路径，跟直觉上的"主目录"不在一起，按目录名排序会排错位置。
关键点在于："盘上有这个版本"和"系统现在跑的是这个版本"之间没有必然联系。 只有操作系统知道后者。
解决
正确顺序是：先问操作系统"你现在跑的是哪一个"，再决定删什么。
# Windows：查某个进程实际加载的可执行文件路径
wmic process where "name='<进程名>.exe'" get ExecutablePath
# 或者用 PowerShell
Get-Process <进程名> | Select-Object -ExpandProperty Path
# Linux：查运行中进程的真实可执行文件
ls -l /proc/<PID>/exe
readlink -f /proc/<PID>/exe
拿到运行中的进程路径之后，再动手：
- 把"当前运行路径"及它所在的目录，明确列进保护名单；
- 检查一下命令入口文件内部的指向关系，确认它实际调用的目标；
- 只删保护名单之外、且确认没有任何进程引用的旧版本目录；
- 删除前后各记一次进程数和相关进程的路径，确认没有发生变化。
如果拿不准，就退一步：先只移走（改名或挪到别处），观察一段时间确认系统一切正常，再真正删除。删除是不可逆的，移走随时可以还原。
延伸与预防
这条坑的通用教训是：清理多版本软件前，先问操作系统"你现在跑的是哪一个"。
这个思路在很多"清理磁盘"的场景里都成立，因为清理的本质是"判断哪些是活的、哪些是死的"，而判断依据必须是"有没有人在用"，不能是"看起来旧不旧"：
- 内核模块：删某个包之前，先看它有没有被加载（
lsmod之类），正在用的不能直接卸； - 共享库：好几个版本共存时，别的程序可能依赖其中某个特定版本，光看版本号排序会误删被依赖的那个；
- 语言运行时 / 虚拟环境：多个解释器并存时，脚本里写死的绝对路径可能指向"较旧"的那个——版本号低的未必没人用。
一个习惯：把"判断哪些能删"这一步，从"按文件名/版本号排序"改成"先列出所有引用关系"。 谁是活的、谁被谁依赖、谁现在正被打开，把这些查清楚，再谈删除。多花五分钟核实，能避免一次不可逆的破坏。删除从来不是"我确定它没用"，而是"我验证过它没被用"。