开发者机器的卫生学：npm、pip、Docker 及其他

一台开发笔记本就是一座顶上拧着 IDE 的垃圾工厂：每个包管理器都在缓存，每个项目都拖着自己那片依赖森林，每个容器运行时都留着早已无人引用的层。磁盘不会在某个下午突然死掉——它是被一点点蚕食的——可行的对策是固定每季度一次的审计，而不是慌乱重装。

开发盘究竟去了哪里

四大囤积户从来不会让看过一眼的人吃惊：包缓存无上限增长，因为默认就是如此；node_modules 在每个项目里复制一遍依赖树；Docker 攥着它拉取或构建过的每一层；WSL2 把整个 Linux 文件系统关在一个按需增长、从不自动收缩的虚拟磁盘里。再加上 IDE 索引、构建产物和并排躺着的三个 SDK 版本，一台两年的机器会若无其事地驮着几十 GB 有据可查的死重。这里没有任何神秘之处——垃圾只是散落在十几个你从不光顾的目录里。

npm：%LOCALAPPDATA%\npm-cache——你装过的每个包的每个版本的完整副本
pip：%LOCALAPPDATA%\pip\cache——所有东西的 wheel，外加每个 WSL 发行版里的 ~/.cache/pip
Docker Desktop：悬空镜像、已停止的容器、构建缓存和匿名卷——docker system df 显示总量，docker system prune 负责回收
WSL2：发行版的 ext4.vhdx 文件随每次构建增长，不强制压缩就绝不归还空间
项目：废弃仓库的 node_modules 从几百 MB 到数 GB 不等——价值在 lockfile 里，文件夹随时可重建
IDE：JetBrains 的缓存和索引目录，外加散布在每个 checkout 里的 target/、build/、dist/、obj/ 文件夹

季度大扫除，按正确顺序

先测量，好把这一小时花在有分量的地方：对用户配置文件跑一个 treemap 工具，容器那边看 docker system df，发行版看 wsl --list --verbose。然后从安全做到危险：缓存会按需重建，所以放心清——npm cache clean --force、pip cache purge，以及 Gradle 和 cargo 里的等价命令；接着是废弃项目——删依赖文件夹，留 lockfile，等仓库哪天醒来，npm ci 或 pip install -r 几分钟就能重建一切。Docker 排在后面：清掉悬空镜像和构建缓存，留下你真正会运行的带标签镜像。最后是 WSL2 虚拟磁盘，因为发行版内部的删除并不会缩小 Windows 一侧的文件：先跑 wsl --shutdown，再压缩 vhdx——如果它真的膨胀成了怪物，就把发行版导出后重新导入。

让磁盘保持平坦的习惯

把卫生当习惯，比把卫生当急救便宜。工具按项目放置而不是全局安装；让 CI 去拉新镜像而不是在本地囤积；每月赶在层的动物园产生记忆之前跑一次 docker system prune。把数 GB 的数据集放到第二块盘再链接进来，让系统盘只装可再生的东西。还有，把快满的 C: 当成构建事故而不是仪容问题——npm、Docker 和编译器工具链，会在它们抓挠的磁盘耗尽时以各种富有创意的方式开始失败。