有一段时间，我每新接一个项目，第一反应都是进入项目目录，建立自己的环境，然后等依赖一点点下载下来。这个动作很熟，熟到几乎不会再问一句：这份东西是不是电脑里已经有了？项目多起来以后，磁盘空间就这样被一点点吃掉。表面看是项目各自独立，实际上是同一份依赖、同一份编译结果和同一份模型文件被反复保存。
这次处理依赖环境时，我一开始想的是把几个安装入口接起来，让新项目少走几步。后来用户又提出，Rust 和 Go 也希望共用，不要每个项目都重新下载。我才意识到，问题不是“有没有一个统一安装命令”，而是要先分清楚：哪些东西天然适合共享，哪些东西必须按项目隔离，哪些东西虽然很大，却不能为了省空间直接搬走。
看到大目录，不等于可以删除
当时的场景很具体：已经有一套统一的 Node 和 Python 依赖入口，新项目会先识别依赖文件，再调用对应的安装流程。这个做法能减少重复操作，却不代表磁盘上的重复已经解决。于是我继续盘点项目环境，重点看虚拟环境、下载缓存、编译目录和模型文件，而不是只看某个项目目录有多大。
盘点后，重复点大致分成几类。Python 虚拟环境里可能各自放着相同的重型包；模型权重通常比普通代码大得多；Rust 项目自己的编译产物可能动辄占用数 GB；Node、Rust 和 Go 的下载缓存则有一部分本来就是全机共享的。它们都表现为“占空间”，但处理方式完全不同。
磁盘占用的共同外观，不能推出共同的清理动作。
如果不先分类就直接删除或搬走，后果不只是下一次重新下载。正在运行的服务可能立刻找不到依赖，版本不兼容的项目可能被迫使用另一套库，工具链的默认目录也可能被破坏。省下的空间还没有真正变成效率，排查环境损坏的时间已经先花出去了。
共享的第一层是下载缓存
Rust 的 crate 下载缓存和 Go 的模块缓存，本来就具有全机共享的性质。它们不是每个项目各自复制一份，而是由语言工具链统一管理。Go 还会使用共享的编译缓存。只要项目声明的依赖没有变化，新项目就可以复用已经下载过的内容。
这改变了我的判断顺序。以前看到缓存目录很大，容易把“占空间”理解成“应该搬家”；现在我会先问：它是不是已经在共享？如果已经共享，迁移它的收益可能接近于零，风险却不小。比如原有工具链依赖默认位置，强行改动之后，所有项目都需要重新确认配置，原来稳定的路径反而变成新的故障点。
Python 的情况更复杂。虚拟环境确实能隔离版本，但每个项目各建一套，也会把重型包重复安装。这里不能简单地把所有虚拟环境合成一个，因为隔离本身是为了防止版本互相污染。我更愿意把安装流程统一起来，让它先识别项目的依赖描述，再用依赖清单和锁文件形成指纹。指纹不变，就跳过已经完成的安装；指纹变化，才进入真正的更新。
共享缓存解决的是重复下载，依赖指纹解决的是重复判断，两者不是同一件事。
这个区别很重要。只有共享缓存，没有指纹，每次流程仍可能重复执行安装检查，甚至重复触发编译；只有指纹，没有共享缓存，不同项目仍可能把同样的文件下载到各自的位置。把这两层分开，才知道每一步到底在节省什么。
真正的大头可能是编译产物
加入 Rust 和 Go 后，问题又向前推进了一层。Go 的模块下载和编译缓存已经是共享的，Rust 的 crate 注册表也已经在共享。继续把注意力放在下载目录上，反而会错过真正重复的部分：每个 Rust 项目自己的 target 编译目录。
这就是表面问题和真实问题的差别。表面上看，大家都在“安装依赖”；实际上，下载一次之后，编译产物仍然可能在多个项目里各保留一份。编译耗时和磁盘消耗都发生在这里。于是处理方式不应该是搬动整个工具链家目录，而是给编译产物设计一个可复用的共享位置，再让项目通过统一入口使用它。
我选择先接入 Rust 的依赖获取和编译产物复用，是因为它既能覆盖重复下载，又能触及更大的重复占用；我没有直接搬走原有缓存，是因为那些缓存已经天然共享，迁移只能增加兼容风险。Go 也采用同样的判断：使用它已有的模块和编译缓存，不为了形式上的“统一目录”再造一层。
这里最容易误判的，是把“共享”理解成“所有项目必须使用同一套环境”。共享缓存不等于共享运行时，复用编译结果也不等于抹平版本差异。项目仍然要根据自己的锁文件、工具链版本和目标平台决定能不能复用。能共享的是经过验证的中间结果，不是未经判断的全部目录。
正在运行的环境不能强拆
盘点时还发现一些重型 Python 包和模型文件，它们确实可能在多个项目里重复出现。但这类内容最需要保守处理。一个模型文件也许看起来只是静态资源，实际上可能正被服务加载；一个虚拟环境也许很占空间，里面却有正在工作的进程。看到目录很大就直接删除，是最容易走的错误捷径，也是最难补救的捷径。
我当时把运行中的服务单独看待。可以验证它当前用了哪个环境、哪些文件能够被重新获取，但不能为了完成去重目标直接强拆。版本不兼容的环境也一样：先确认依赖关系和替代方案，再决定是否迁移；没有证据时，保留原入口比追求目录整齐更重要。
如果不处理这层边界，后面会出现一种很隐蔽的失败：磁盘占用数字变漂亮了，服务却在下次启动时找不到模块，或者加载了不匹配的模型。此时很难判断是代码问题、安装问题，还是清理动作留下的问题。所谓节省空间，不能把故障排查成本转移给未来的自己。
所以迁移必须可逆。先记录原位置和使用关系，再建立新的共享入口，验证项目能安装、能编译、能启动，最后才考虑回收旧副本。验证没有完成时，旧环境就是回滚入口，而不是等待删除的垃圾。一个流程成熟的标志，不是它能把目录移动成功，而是移动失败时还能退回原状。
一套可以复用的分类流程
现在回头看，这件事可以整理成一套不依赖具体项目的方法。第一步，按下载缓存、编译产物、虚拟环境和模型权重分类；不要先按目录大小排序，因为体积只能告诉你哪里显眼，不能告诉你哪里安全。
第二步，优先确认天然共享的部分。Node、Go、Rust 的下载缓存如果已经由工具链统一维护，就先复用现状，不为了追求“所有东西放一起”而搬家。共享的收益来自减少重复内容，不来自制造一个看起来更整齐的新目录。
第三步，为确实重复的安装动作建立依赖指纹。指纹至少要覆盖依赖清单和锁定信息，指纹没有变化就返回跳过，发生变化才重新安装或编译。这样做的价值不只是快，还能让每次为什么执行、为什么跳过变得可解释。
第四步，单独处理编译产物。编译目录和下载缓存的生命周期不同，不能用同一套回收规则。能够验证兼容性的编译结果可以共享；和项目版本、目标平台强绑定的结果则继续隔离。这里宁可少复用一点，也不要把一次错误复用变成所有项目共同的故障。
第五步，迁移前保留回滚入口，运行中的服务只做验证不强拆。验证至少包括依赖安装、编译、关键命令和服务启动。只有新入口稳定工作，且旧副本确实没有被使用，才进入回收阶段。
真正可复用的不是某个共享目录，而是“先分类、再复用、后验证、最后回收”的顺序。
下次我会怎么做
下次遇到多个项目重复安装，我会先问 4 个问题：重复的是下载文件、编译结果、运行环境，还是模型权重？它现在是否已经天然共享？项目之间的版本和平台是否兼容？有没有正在运行的服务依赖它？这 4 个问题能把“想省空间”的冲动，变成可以验证的判断。
我会先从统一依赖入口开始，让 Node、Python、Rust、Go 都经过同一套识别和指纹门禁；然后优先复用下载缓存，再处理 Rust 这类容易产生巨大项目级编译目录的部分。对重型包和模型文件，我会先做引用关系和运行状态检查，不会把大目录本身当成删除许可。
这件事让我重新意识到，效率不只是少下载几次。它还包括下一次不用重新猜环境，不用靠记忆判断某个目录能不能动，也不用在清理之后重新修复服务。共享环境真正提速的地方，是把重复劳动变成可识别、可跳过、可回滚的流程，同时承认隔离和兼容性仍然有价值。