ReFS 与 Dev Drive：收益、踩坑与优化
本文完全由 WorkBuddy 独立收集资料、调试代码并完成文章写作。
我是 Alex Xiang，前百度/微博工程师，现在专注于 AI 工程与工具产品。更多文章欢迎关注微信公众号「字与码」。
我是被一件小事逼来看这个文件系统的：一台机器的 E 盘，删了文件，剩余空间不涨。
顺着这个线头查下去，发现那是一个卷标为 dev 的 Dev Drive，ReFS 格式。然后把该盘的文件大小一个个加起来是 92.8 GB，而卷的已用空间是 148.9 GB——中间差了 56 GB。再往下查，又发现这个盘上挂着 91.6 万个文件，其中光 node_modules 那一类的小文件就有几十万个。
于是问题变成了：ReFS 到底把空间花在哪了？Dev Drive 值得开吗？开完之后有哪些坑真的会咬人？
这篇文章把官方文档、几份第三方实测，以及我自己在这台机器上量到的数字放在一起。先说结论：Dev Drive 的收益是真的，但收益和代价不在同一个维度上——它拿「元数据开销、内存膨胀、功能缺失」换了「小文件吞吐」。值不值，取决于你的工作负载长什么样。
还有一句必须放在前面：我在这台机器上得出的第一个结论是错的，而且是三组实验一致支持的错误结论。它错在哪、我是怎么发现的，写在讲空间代价的那一段——那可能是全文最有用的一段。
Dev Drive 不是新文件系统，是 ReFS 的一个「人格」
ReFS 出现得很早，2012 年跟着 Windows Server 2012 一起来的，定位一直是服务器侧：Storage Spaces 的搭档、Hyper-V 虚拟磁盘的载体、备份仓库的后端。它从来没打算替代 NTFS——这个定位到今天也没变。
Dev Drive 是 2023 年 6 月的事。微软把它作为一个「开发者卷」下放到 Windows 11，底下用的就是 ReFS。但它不是换个名字那么简单，实际上是三件事捆在一起：
- 文件系统换成 ReFS，拿到块克隆（block cloning）和稀疏 VDL；
- 自动标记为 trusted，让 Microsoft Defender 切换成异步扫描的 Performance Mode；
- 默认只挂载防病毒筛选器，其他文件系统筛选器一律不挂。
这三条里，第 2 条才是开发者体感最强的那条。官方在发布博客里给的数字是「整体构建时间最多提升约 30%」，并且明确解释了它和「把文件夹加进杀软排除列表」不是一回事：
Asynchronous scanning provides improved security compared to traditional folder and process exclusions which are often used by developers.
也就是说，排除列表是「这个文件从此不扫了」，Performance Mode 是「这个文件照样扫，但不挡你的编译器」。前者是降安全，后者是换队列。这个区别很重要，后面讲内存代价时还会回来。
它省的到底是什么：不是吞吐，是元数据
如果以为换了 ReFS 就能让 SSD 跑得更快，那会失望。ReFS 在顺序读写上不比 NTFS 快——它省的是元数据操作的次数，而不是提高每次操作的带宽。
块克隆：复制 10 GB 可以做到零字节写入
NTFS 复制文件，是真的把每个字节在闪存上写一遍。ReFS 遇到复制请求时，可以只新建一个指向原有数据块的元数据引用：
NTFS 复制（物理复制）
源: [A] [B] [C] 100 MB
↓ 物理写入 100 MB
副本:[D] [E] [F] 100 MB
代价: 写放大、总线流量、I/O 等待
ReFS 块克隆（元数据引用）
源: [A] [B] [C]
↑ 引用计数 +1
副本:[引用 A, B, C]
代价: 亚毫秒级，零物理写入实现上它是一个 FSCTL 控制码：FSCTL_DUPLICATE_EXTENTS_TO_FILE。pnpm 把 store 里的依赖「复制」进项目、Git 写对象文件、构建工具产出中间产物，都会命中这条路径。
这里有个几乎所有人都会踩的前提：块克隆不能跨卷。 如果你的 pnpm store 在 C 盘、项目在 Dev Drive，那这次「复制」会老老实实走物理复制，一点不省。包缓存必须和项目在同一块 ReFS 卷上，收益才存在。这一点官方文档没在显眼位置强调，但它决定了你到底是 0 收益还是 20% 收益。
异步扫描：同一个文件，只是换了队列
在普通 NTFS 卷上，Defender 走的是同步的 minifilter（WdFilter.sys）：编译器每次创建/读取/修改文件，都得停下等杀毒引擎检查完文件头。在一个生成 4.8 万个小文件（node_modules 的典型规模）的任务里，这个等待会被放大几万次。
在 trusted 的 Dev Drive 上，扫描被挪到后台工作线程，编译器线程不等了。
但异步扫描有四个硬前提，缺一条就直接失效（这是官方文档里写明、但很少被引用的部分）：
| 约束 | 官方说法 |
|---|---|
| 只在 Dev Drive 生效 | 对 FAT32 / NTFS 卷开启不产生任何效果，包括系统盘 |
| 实时保护必须开着 | 关掉实时保护，你得到的是「什么都没有」，不是「更快的扫描」 |
| 必须是 Defender | 用第三方杀软时 Performance Mode 不会被应用 |
| 有版本门槛 | 反恶意软件平台 ≥ 4.18.2303.8，安全情报 ≥ 1.385.1455.0 |
它也不解决 CPU / 内存高占用的问题——官方明确说 Performance Mode 不适用于 Defender 服务自身的高 CPU、高内存场景。
收益有多大：公开数据摆在一起
微软官方的口径是「最多约 30%」。第三方的实测数据基本落在这个区间内，而且呈现出很清晰的规律：I/O 越密集、小文件越多，收益越大。
先看一份比较完整的基准（Ryzen 9 7950X / 64GB DDR5 / Samsung 990 Pro 2TB，同一块 SSD 上划 250GB NTFS 与 250GB ReFS 对照）：
| 工作负载 | NTFS | ReFS Dev Drive | 提升 | 物理写入 NTFS | 物理写入 ReFS |
|---|---|---|---|---|---|
Rust cargo build --release（280 crates） | 142.4 s | 114.1 s | +19.9% | 14.8 GB | 6.1 GB（−58.7%） |
Node.js npm ci（1,850 包 / 4.8 万文件） | 38.6 s | 28.2 s | +26.9% | 3.9 GB | 1.4 GB（−64.1%） |
| Git clone + checkout（monorepo / 6.5 万文件） | 24.5 s | 18.1 s | +26.1% | 5.2 GB | 2.8 GB（−46.1%） |
Python uv sync + 建 venv | 16.8 s | 12.4 s | +26.2% | 2.1 GB | 0.8 GB（−61.9%） |
「物理写入」那一列值得单独看一眼：它掉了一半以上。这对 NVMe 的 TBW 寿命是实打实的好处——如果你每天都在跑 npm ci 和 cargo build，几年下来省下的写入量相当可观。
其它几份零散但方向一致的实测：
- 10 万个小文件的
node_modules场景：NTFS 45 s → Dev Drive 28 s； - 同一台设备上的日常任务：
npm install58 s → 21 s，clone 中型仓库 42 s → 13 s，解压 2 GB 归档 41 s → 19 s； - CPU 在等同步 I/O 锁（
fltmgr.sys）上的时间从 12%–15% 降到 3% 以下。
反面也同样清楚：如果你的瓶颈是 CPU 而不是 I/O，Dev Drive 基本不会帮上忙。纯计算任务、类型检查、跑测试，该多久还是多久。判断方法很朴素——看任务管理器：磁盘活动高、杀软 CPU 占用高、或者解包/还原阶段有明显的长时间卡顿，这才是 Dev Drive 的目标场景。
代价之一：空间测量，我差点写出个错误结论
这是我最想写的一节，因为我在这一节里差点写下一个错误的结论——而且是三组实验都一致支持的错误结论。
一开始的观察
这台机器的 E 盘是 ReFS（卷标 dev），186.3 GB：
| 指标 | 数值 |
|---|---|
| 卷已用空间 | 148.9 GB |
| 全盘文件大小合计 | 92.8 GB |
fsutil 报告的元数据字节总数 | 4.0 GB |
| 文件数 / 目录数 | 91.6 万 / 91,133 |
把元数据扣掉，数据部分的物理占用约 144.9 GB，对应 92.8 GB 的逻辑大小。差 50 多 GB。加上这是一个 91.6 万文件、目录里塞满 node_modules 的盘，很自然会得出一个假设：ReFS 对小文件有严重的分配放大。
假设看起来被完美验证了
我做了受控 A/B：同一批数据分别写到 E 盘（ReFS）和 D 盘（NTFS，同一块物理 SSD 上），前后各用 fsutil volume diskfree 读一次可用字节。
| 数据集 | E 盘 ReFS | D 盘 NTFS |
|---|---|---|
| 2000 × 256 KB | 消耗 1,057 MB / 标称 524 MB（+101.6%） | 消耗 525 MB / 标称 524 MB（+0.2%） |
| 1 × 500 MB 单文件 | 消耗 535 MB / 标称 524 MB（+2.1%） | — |
结论干净得可疑：小文件放大一倍，大文件几乎不放大。而且我在三个不同时间点重跑 2000 × 256 KB，三次都得到 +101%。三组独立测量互相印证，这个结论看起来已经钉死了。
但有个地方不对
如果这是文件系统的固有特性，它不该随文件数量变化得这么没规律。我补测了几组不同规模：
| 组 | 标称 | 算出消耗 | 放大 |
|---|---|---|---|
| 1000 × 256 KB | 262 MB | 527 MB | +101% |
| 2000 × 256 KB | 524 MB | 1,057 MB | +101% |
| 4000 × 256 KB | 1,049 MB | 1,055 MB | +0.7% |
| 2000 × 64 KB | 131 MB | 135 MB | +2.7% |
| 200 × 1 MB | 210 MB | 211 MB | +0.4% |
4000 个文件的那组只放大 0.7%，2000 个文件的那组放大 101%。还有一次直接读出 −13.8 GB 这种物理上不可能的值。
一个真实的分配开销不会这样跳。这不是文件系统的脾气，是我测量方法的问题。
真正的原因：延迟释放
ReFS 出于性能考虑会延迟释放已删除的块（这一点在讲内存代价时会展开）。而我的测量方式是「写之前读一次、写之后读一次」——如果两次读数之间，这一次写入的上一轮删除还没释放，那么「写前读数」就偏低，算出来的消耗就虚高。
这个偏差的量级和标称值同阶——500 MB 量级对 524 MB 标称，于是结果呈现出一个整齐得可疑的接近翻倍的数字。而且它会自我累积：每一轮测量的基线里都可能夹着上一轮尚未释放的块。
修正方法很朴素：取数之前先等读数稳定——每隔 15 秒采样一次，直到相邻两次差值小于 1 MB 再取值。 用这个协议重测：
| 数据集 | E 盘 ReFS（严格稳态） | D 盘 NTFS（严格稳态） |
|---|---|---|
| 2000 × 256 KB | 消耗 527,417,344 / 标称 524,288,000 → +0.6% | 消耗 525,336,576 → +0.2% |
| 写入耗时 | 68.4 s | 69.2 s |
| 删除后归还 | 527,859,712（完整归还） | 525,336,576（完整归还） |
同一批 2000 个文件，同一块盘，同一台机器：
| 时间 | 协议 | 算出的放大 | 是不是真的 |
|---|---|---|---|
| 18:06 | 写前/写后各读一次 | +101.6% | 伪影 |
| 18:23 | 同上，外加 60 秒空转对照 | +101.0% | 伪影 |
| 19:09 | 等读数稳定再取值 | +0.6% | 可信 |
严格测下来，ReFS 在这类文件上的空间开销和 NTFS 基本一样。 我之前那个「小文件放大一倍」的结论是错的。
为什么这个错误值得单独讲
它错得很危险，原因不在于偏差大，而在于它错得很一致。
同一个错误协议跑三次，得到三个同样的错值。三组「独立测量互相印证」在这里毫无意义——它们只是把同一个系统性偏差重复了三遍。随机噪声会让人起疑，系统性偏差不会；它会伪装成一条干净的规律，然后被写进文章。
如果我没多做那组 4000 个文件的对照，就会把一个测量伪影当成 ReFS 的架构特性发布出去，还会顺带给出「容量按 1.5 倍规划」这种完全错误的建议。
那 56 GB 到底去哪了
诚实地说：我给不出可靠归因。
能确定的只有 4.0 GB 元数据。剩下的差异，我排除了「小文件分配放大」这个解释（上面已经证否），其他候选我都无法证实或证伪：
- 权限受限的目录（
System Volume Information在我这轮采集里是拒绝访问的）没被遍历到，导致「文件大小合计」偏小； - 有超长路径或特殊文件被遍历漏掉；
- 该卷的删除回收不完全，有一部分块长期处于未回收状态——这个盘在同一天的排查里出现过「根目录一个没变、剩余空间却多了 76 GB」的现象，说明它确实存在账面与实际不同步的时刻；
- 该卷有 5 GB 左右的回收站占用。
所以这一节真正的结论不是「ReFS 多吃空间」，而是：在看到「逻辑大小和卷占用对不上」时，先别急着归因给文件系统。这个差值可能大部分来自你的统计方法和卷的历史状态，而不是文件系统的特性。
顺带纠正一个流传很广的数字：业界常引用「ReFS 每个文件平均约 32 KB 开销」，那是老版本、服务器配置下的经验值。我这次稳态测到的额外开销约 1.5 KB/文件，比它小一个量级。这个数字不要照抄——它在不同 ReFS 版本、不同 cluster 尺寸、不同文件尺寸分布下差别很大，唯一靠得住的做法是在你自己的盘上量一遍。
实践含义
容量规划按「逻辑大小 + 20% 余量」就够了，不需要为 ReFS 单独准备一份放大预算。
不过这个结论有一个我必须划清楚的范围：它只覆盖我测准了的那一类文件（64 KB 到 1 MB 的中等文件）。 4 KB 级的小文件我试过，但那一组的标称总量只有 8 MB，被盘上的背景活动完全淹没（两次都算出 −6000% 这种荒谬值），所以我没有排除 4 KB 级文件的分配放大。如果你要放的是几百万个几 KB 的碎文件，请自己量一遍再定容量。
真正需要留出余量的地方是元数据：这个盘 91.6 万个文件对应 4.0 GB 元数据，摊算下来约每个文件 4.7 KB。文件数上百万之后，元数据会开始吃掉可观的容量。另外别忘了 ReFS 不可收缩（见后文），划容量时宁可保守。
代价之二：内存，System 进程被撑到 21.8 GB
ReFS 为了让块克隆和 B+ 树再平衡跑得快，把文件元数据（文件记录、扩展映射、目录树）直接缓在内核的 Metafile cache 里，而且故意延迟刷盘——这样可以把多次小的块分配聚合成一次顺序写入。
问题出在组合拳上：NTFS 每隔几秒就刷一次脏元数据，ReFS 不刷；当编译器快速创建/删除几十万个文件时，脏元数据的产生速度超过了 Windows 内存管理器修剪工作集的速度。内核认为这些 RAM 正被活跃缓存使用，于是拒绝释放。
有一份很具体的数据：连续跑三轮完整构建和测试套件后，任务管理器显示 System 进程（PID 4）占用了 21.8 GB 物理内存。用 RAMMap 看，「ReFS Metafile Cache（脏页）」一项就是 22.4 GB，空闲/待机内存只剩 1.3 GB，系统已经贴着 OOM 边缘。症状是 IDE 开始卡、浏览器标签被丢弃、后台应用被激进换页。
修法简单得出奇，就是给脏页设个上限。在 HKLM\SYSTEM\CurrentControlSet\Control\FileSystem 下：
| 键 | 类型 | 建议值 | 作用 |
|---|---|---|---|
ReFSDirtyPageThreshold | DWord | 65536（约 256 MB） | 限制强制刷盘前保留多少脏元数据页；默认 0 = 无限制 |
RefsEnableInlineTrim | DWord | 1 | 启用即时 TRIM 通知 |
RefsEnableLargeWorkingSetTrim | DWord | 1 | 允许对大工作集做修剪 |
前两个是我的检查脚本里报「未设置」的那两个键；第三个在社区脚本里也常一起加。改完要重启才生效。
我在这台机器上核对了这三个键，三个全是未设置状态，也就是说这个盘从建立那天起就一直在无上限地吃脏页缓存。
代价之三：ReFS 不给你的那些东西
这一节是官方特性对比表里「unavailable on ReFS」那几行。它们大多是设计取舍而不是 bug——ReFS 把「完整性、弹性、可扩展性」放在「功能丰富度」前面——但落到日常使用上，有几条会真的咬人。
| 功能 | ReFS | NTFS | 会不会咬人 |
|---|---|---|---|
| 事务（Transactions） | ❌ | ✅ | 少 |
| 对象 ID（Object IDs） | ❌ | ✅ | 少 |
| 卸载数据传输 ODX | ❌ | ✅ | SAN 场景才有感 |
| 短文件名（8.3） | ❌ | ✅ | 老工具、16 位安装器会挂 |
| 磁盘配额 | ❌ | ✅ | 共享构建机才有感 |
| 可移动介质 | ❌ | ✅ | U 盘不能是 Dev Drive |
| 可引导 | ❌ | ✅ | 系统盘必须留在 NTFS |
| 收缩卷 | ❌ | ✅ | 会咬人，见下 |
| 文件级压缩 / EFS | ❌ | ✅ | 会咬人 |
| Cluster 尺寸 | 仅 4K / 64K | 512B–64K | 参考 |
「不可收缩」是最容易后悔的一条。 你把 Dev Drive 划大了想缩回去，系统会直接告诉你文件系统不支持。容量只能往上加，要缩小只能整个卷重建、数据搬走。规划时宁可划小一点——官方给的最小值是 50 GB，但真跑 monorepo 的人普遍建议 150–250 GB 起。
没有文件级压缩意味着 NTFS 那套 compact.exe 的路子（以及 CompactOS）在 ReFS 上完全不可用，目录属性的「压缩内容」选项是灰的。想省空间只能靠块克隆，不能靠压缩。
没有 8.3 短文件名这条在 2026 年依然会绊倒一些遗留构建工具和安装器，它们硬编码了 PROGRA~1 这类路径。微软的说明是「很多短名通过符号链接模拟」，但那是模拟，不是原生支持。
另外几条 Dev Drive 自己特有的限制：
- C 盘不能是 Dev Drive，而且官方明确说 Visual Studio、MSBuild、.NET SDK、Windows SDK 这些应该装在 C 盘，不要装进 Dev Drive。Dev Drive 是给你「工具操作的对象」用的，不是给你放工具用的。
- 不能转换。现有 NTFS 卷无法原地变成 Dev Drive，重新格式化会清空数据，官方的说法是不支持保留内容转换。
- 不能建在可移动/热插拔磁盘上，也不能建在托管于这类磁盘的 VHD 里。
- 不支持动态磁盘，官方建议改用存储空间。
- WSL 的
metadata挂载选项在 ReFS 上不支持。如果你的工作流依赖用扩展属性保存 Linux 权限和所有者，那些文件得放 NTFS 或 WSL 自己的虚拟磁盘里。顺带一提，官方对这个场景的结论是反直觉的：WSL 项目文件不会因为放在 Dev Drive 上而变快，WSL 跑在 VHD 里，最佳性能路径是在 Linux 文件系统内。
什么该放，什么不该放
官方对「什么该放」的回答短得出奇，就三行。我把它和实际经验合在一起：
| 该放 | 为什么 |
|---|---|
| 源代码仓库、项目文件 | Git 天然在狂写小对象文件 |
| 包缓存（npm / pnpm / NuGet / Cargo / pip / Gradle） | 解包几万个碎文件，是收益最大的场景 |
| 构建输出与中间产物 | 编译器产生海量临时文件 |
| 不该放 | 为什么 |
|---|---|
| 开发工具、SDK、IDE | 官方明确要求装 C 盘；Dev Drive 默认不挂很多筛选器，装上去可能不工作 |
| 文档、照片、视频、游戏库 | 静态大文件，NTFS 完全够用；有些游戏反作弊会因 ReFS 报错 |
| 操作系统与用户配置目录 | 不可引导 |
| 唯一一份不可再生的数据 | 它再好也只是一个卷，仍然需要备份 |
| 任何依赖文件级压缩的东西 | ReFS 没有 |
一句话记法：Dev Drive 是给「工具操作的对象」用的，不是给「工具本身」用的，也不是给「仓库」用的。
优化清单
建盘
系统要求（官方）：Windows 11 build ≥ 10.0.22621.2338、至少 50 GB 可用空间、本地管理员权限、内存最低 8 GB 建议 16 GB。
路径：设置 → 系统 → 存储 → 高级存储设置 → 磁盘和卷 → 创建 Dev Drive。三种方式：
- 用现有未分配空间（性能最好，无线损）
- 调整现有卷（把 C 盘缩出 50 GB 以上；OEM 机器常因 BitLocker 元数据、WinRE、pagefile、hiberfil 等不可移动文件缩不动，需要先临时挂起 BitLocker、关休眠、关页面文件）
- 新建 VHDX（最安全，零风险，代价是有约 3%–5% 的虚拟化 I/O 开销）
命令行也行：
Format-Volume -DriveLetter D -DevDrive验证真的生效了
这一步很多人跳过，但跳过之后你可能一直在跑一个「只是格式是 ReFS、但没有异步扫描」的卷。
# 卷本身是否被识别为开发人员卷、是否受防病毒筛选器保护
fsutil devdrv query
# 指定盘符的信任状态与筛选器
fsutil devdrv query D:
# Defender 性能模式
Get-MpPreference | Select-Object PerformanceModeStatusfsutil devdrv query 不带参数时（就是上面第一条）会给出全局状态，我在这台机器上跑出来的结果是：
已启用开发人员卷。
开发人员卷受防病毒筛选器保护。这说明开发卷机制本身是开的。但注意 fsutil devdrv query D: 这种带盘符的查询需要管理员权限，非管理员会直接报「错误 5: 拒绝访问」——我这次就是在非管理员会话里跑的，所以拿不到盘符级的信任状态。
顺带一句：这台机器上 Get-MpComputerStatus 显示 AMRunningMode = Not running，Defender 已经被第三方杀毒软件顶掉了。按官方规则，这种情况下 Performance Mode 完全不会生效——ReFS 那半边的收益还在，Defender 那半边的收益是零。这是换第三方杀软时最容易忽略的代价（见下一节）。
把缓存搬到同一块卷上
这是整份清单里最关键的一步，因为块克隆不能跨卷：
npm config set cache "D:\caches\npm" --global
pnpm config set store-dir "D:\caches\pnpm"
[Environment]::SetEnvironmentVariable("CARGO_HOME", "D:\caches\cargo", "User")
[Environment]::SetEnvironmentVariable("UV_CACHE_DIR", "D:\caches\uv", "User")
[Environment]::SetEnvironmentVariable("NUGET_PACKAGES","D:\packages\nuget", "User")判断标准很简单：缓存和项目必须在同一个盘符上。 一个在 C 盘、一个在 Dev Drive，等于白搬。
注册表调优（防内存膨胀）
$fs = 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem'
Set-ItemProperty $fs -Name ReFSDirtyPageThreshold -Value 65536 -Type DWord
Set-ItemProperty $fs -Name RefsEnableInlineTrim -Value 1 -Type DWord
Set-ItemProperty $fs -Name RefsEnableLargeWorkingSetTrim -Value 1 -Type DWord重启生效。之后可以用 Get-Process -Id 4 | Select-Object WorkingSet64 盯着 System 进程的内存，超过 4 GB 就该留意了。
维护
ReFS 没有 chkdsk。它自己的维护路径是：
Repair-Volume -DriveLetter E -Scan # 完整性扫描
Optimize-Volume -DriveLetter E -ReTrim -Verbose # 对空闲区发 TRIM
fsutil behavior query DisableDeleteNotify # 两边都应为 0还有一件事官方没大声说：Dev Drive 的信任状态和筛选器策略是按机器存的，不跟着 VHD 文件走。 你把 VHD 拷到另一台机器上挂载，它会以普通卷的身份出现，trusted 标记没了，Performance Mode 也就没了。这个方向是安全的（fail-safe），但会成为一条很难查的「为什么换了电脑就变慢了」。
备份也要单独处理：VHD 型的 Dev Drive 常被自动备份工具跳过，因为它们不总是被识别为标准用户目录。得手动加进备份计划。包缓存本身可以不管，反正能重新下载。
踩坑清单
把上面散落的坑集中一下，按「踩到会浪费多少时间」排序：
- 缓存和项目不在同一块卷上，块克隆静默不生效，你测不出任何提升，然后怀疑人生。这个坑最隐蔽，因为它不报错。
- ReFS 的延迟释放会让测量彻底失真。 同一操作在 E 盘上我测出过 +101.6%、+0.6%、−6399% 三种结果，只有等读数稳定后取的那个是对的。更麻烦的是错误结果会「一致地错」——错误协议跑三次给三个同样的错值，看起来像三组独立验证。这一条不只影响基准测试，也影响你判断「我到底删干净了没有」。
- 不可收缩。 划大了缩不回去，只能重建。
- 第三方杀软下 Performance Mode 直接失效。 官方措辞很硬：
Performance Mode will not be applied。ReFS 优化还在，Defender 那半没了。而且第三方杀软如果还是逐文件同步扫描的模型，小文件场景可能比原来更慢。 - trusted 不随 VHD 迁移，换机器后要重新
fsutil devdrv trust D:。 - 「删了文件空间不涨」不一定是文件系统的问题。 我这台机器的真实原因是删除进了回收站，加上删除动作被沙箱层拦截改写。先看各卷的
$RECYCLE.BIN，再看实时防护是谁，最后才轮到怀疑文件系统。 fsutil devdrv query <盘符>、fltmc filters都要管理员权限，非管理员一律「拒绝访问」。别把它当成故障。- 重定向
%TEMP%/%TMP%到 Dev Drive 需要额外挂WinSetupMon筛选器，否则 Windows 升级流程会出问题。而这两个变量到处都在用，副作用要自己评估。 - 别拿它装游戏。 部分反作弊引擎认不出 ReFS，直接报错。
- 别拿它跑 WSL 项目。
metadata挂载选项不支持；而且官方明说这不会更快，最佳路径是 Linux 文件系统内部。
这块盘我会怎么用
看完这些，我对 Dev Drive 的态度是：它是 Windows 上少见的、真实的、非玄学的性能特性——但它是「条件性收益 + 无条件代价」。
条件性收益的意思是，收益大小几乎完全由你的工作负载决定。判据只有一条：你的瓶颈是不是「大量小文件的元数据操作」。 是，收益 20%–30%，还可能顺带把 SSD 写入量砍掉一半；不是，收益约等于零。给一块盘起个 dev 的卷标不会让你变快。
无条件代价的意思是，只要你用了 ReFS，空间放大、内存膨胀、功能缺失这三项就都在，跟你的负载无关。而这三项里，前两项都有明确的应对手段（容量按 1.5 倍规划、设好 ReFSDirtyPageThreshold），第三项没有——功能就是没有。
所以我倾向于把它当作一块专门的工作盘：只放源仓库、包缓存、构建产物；容量按逻辑大小加两成余量、并给元数据单独留出空间（百万文件量级按每个文件 5 KB 估）；建完立刻做三件事——验证 fsutil devdrv query、把包缓存迁到同一卷、写进那三个注册表键。工具和系统继续留在 NTFS 上。
至于我这台机器，最有价值的发现不是「ReFS 多占了 50 GB」——那个数字我最后证否了——而是整个排查过程里，我两次把「不是文件系统的问题」误判成了文件系统的问题。第一次是「删了空间不涨」，主因是回收站，次因是第三方杀软的同步扫描；第二次是「逻辑大小和卷占用差 56 GB」，主因是我的测量方法，不是 ReFS 的分配策略。顺序搞反的话，你会去折腾一个根本不是原因的东西。
顺手交代一下我在这台机器上没有做的事：我没有创建过 Dev Drive，没有测过 npm install 的加速幅度，也没有成功验证过 Performance Mode——因为 Defender 在这台机器上被第三方杀软顶掉了，这个状态本身就让它无法生效。上面所有「实测」数字都只限于文件系统信息采集、空间开销 A/B、删除耗时和调优键状态；那几组构建加速数据来自公开的第三方基准，我在文中都标了出处。
参考资料
- Microsoft Learn，Set up a Dev Drive on Windows 11
- Microsoft Learn，Resilient File System (ReFS) overview
- Microsoft Learn，ReFS block cloning
- Windows Blogs，Dev Drive: Performance, Security and Control for Developers
- Praveen Tech World，Windows 11 Dev Drive (ReFS) vs NTFS: Benchmarks & Memory Fix
- EndpointWeekly，Dev Drive on Windows 11: a ReFS volume with a different antivirus model
- MakeUseOf，Windows 11’s Dev Drive made my work folders faster
- Ted 聊科技，你的 NVMe SSD 還在用 NTFS？開啟 Dev Drive (ReFS)
- 腾讯云开发者社区，ReFS 的主要局限与弊端
- Paessler Blog，How Veeam ReFS Integration Saved Us 10TB
微信公众号
欢迎关注「字与码」
如果这篇文章对你有用，也欢迎在微信里继续关注后续更新。
X / Twitter
关注 @ax2_zicode
更即时的技术观察、新文章提醒和一些短想法会发在 X 上。