编辑器的后台检查器填满了我的硬盘，一次 341GB
来源：dev.to — 2026-09-03
📋 概述
作者用 0.82GB 这个 C: 盘剩余数字开场——一台只有单个 NVMe 系统盘的机器，在 Rust 项目于后台滋长数周后被耗尽。项目规则写得很清楚：cargo 只在 WSL 里跑，好让构建产物落在独立虚拟盘上。这条规则对每个在终端构建/测试的人都成立，却没能约束真正打破它的东西：VS Code 的 Rust 扩展运行 rust-analyzer，它在每次保存时自己跑一次后台 cargo check，用自己理解的项目构建目录位置——在 Windows 上就是原生 cargo.exe 与 rustc.exe 往原生 target\debug 写。十七个这类进程被发现同时在写入，建出了 341GB 可由 CACHEDIR.TAG 证实可再生删除的产物。规则没错，只是没约束住打破它的那个写者。
🔑 核心要点
- rust-analyzer 的 flycheck 是独立于人类终端的另一个写者：它从没读过「cargo 跑 WSL」这条规则，也不在乎人约定的惯例，直接往 Windows 原生 target 目录写
- 341GB 只是三处来源之一：WSL 自己的陈旧 cargo target 目录约 630GB，加上 WSL 虚拟盘本身不会因删除内部文件而收缩
- 止血要两件事：杀掉那 17 个存活进程，再关掉三个允许 rust-analyzer 的 flycheck 触碰原生构建目录的 VS Code 设置——否则只是清理一次、再生路径依旧敞开
- 清理加压缩合计回收近 1TB，其中压缩一步把 WSL 容器从 845.4GB 降到 173.4GB，直接测量验证了 672GB 的降幅
- 资源纪律的教训：写下「cargo 构建在 WSL」后，下一个问题必须是「还有谁能写这块资源而我还没点名」——编辑器扩展不是任何人会记得审计的构建步骤，定时任务不是，共享同一 checkout 的另一人会话也不是
- CACHEDIR.TAG 是区分「删了能自动重建」与「猜」的真实标记，用它确认那 341GB 是可再生产物
💡 金句
一条只点名一个写者的规则，面对它没点名的每个写者时早就输了——而在空闲空间归零之前，它一直悄无声息地输着。
👍 0
👎 0
← 返回 dev.to 首页