不碰内核一行代码，在 Windows 上"造"出你的第一个虚拟磁盘：WinFsp 从零实战

【免费下载链接】winfspWindows File System Proxy - FUSE for Windows项目地址: https://gitcode.com/gh_mirrors/wi/winfsp

需求只有一句话：让网盘客户端把云端存储"挂"成用户电脑上的一个本地盘符，像用 C 盘一样直接读写。可这句话背后是个大坑——Windows 的文件 API 只认盘符和 UNC 路径，想让程序"看见"一个并不存在的盘，传统方案只有一条路：写内核文件系统驱动。驱动签名、蓝屏调试、测试机集群，光这三座大山就足以劝退绝大多数团队。Linux 生态早就有标准答案 FUSE（把文件系统挂载交给用户态程序），而 Windows 的对应方案，就是本文的主角 WinFsp——一个让普通开发者不写任何内核代码、就能实现用户模式文件系统的开源框架。

为什么你的云盘客户端需要一个"本地盘"

先讲个真实场景。某备份软件的产品经理提了个需求：用户在资源管理器里右键点击云端文件，直接"另存为"到云端盘符，而不是先下载到本地再上传。这个体验差异，直接决定产品的留存率。但开发一评估就傻眼了——为了一个"虚拟盘"要搭内核驱动开发环境，工期按季度算。

这正是 WinFsp 存在的理由：它把"文件系统驱动"这个内核级工作，拆成了一个内核驱动（负责和 Windows 内核打交道）加一个用户态 DLL（提供开发者友好的 API）。写文件系统变成写普通程序，本质就是 FUSE for Windows。

5 分钟先跑起来：把 MEMFS 挂成 X 盘

先别管原理，先把第一个虚拟盘跑起来，建立信心。

第一步，获取源码（安装包同样可用，但源码里示例最全）：

git clone https://gitcode.com/gh_mirrors/wi/winfsp

安装时务必勾选Developer组件，它会一并带上 MEMFS（内存文件系统）示例、头文件和库文件。

第二步，启动 MEMFS 并挂载：

net use X: \\memfs64\test echo "hello winfsp" > X:\hello.txt dir X:\

挂载成功后，X 盘就是一个真实可用的盘符，echo、dir 全部正常

挂载出来的虚拟盘在资源管理器中和普通磁盘没有区别

你没有写一行驱动代码，却得到了一个货真价实的盘。这种"魔法"是怎么发生的？

设计哲学：把文件系统劈成"内核接线员"和"用户态客服"

打开源码目录会立刻发现一个清晰的分界：src/sys/ 是唯一的内核部分，src/dll/ 是面向开发者的用户态库。整个架构可以类比成接线员 + 客服的关系：

• 内核驱动（FSD）是接线员：它只负责接听 Windows 内核打来的"电话"，把文件请求原样转出去，不处理任何业务；
• 你的程序是客服：真正回答"这个文件多大""把这段数据写进去"等业务问题。

作者在 README 里把这种设计的好处总结为四个字：开发容易、稳定。为什么稳定？因为"客服"挂了（用户态进程崩溃），"接线员"还在，最多这个盘暂时消失，绝不会让整台电脑蓝屏——这正是把业务逻辑搬出内核的最大价值。在 Windows 上，内核崩溃的代价是系统级灾难，而这个设计把风险隔离在了用户态。

最难懂的部分：一次 WriteFile 的"快递之旅"

那么问题来了：一次写入请求，从应用层到你的代码，中间到底是怎么"旅行"的？这是 WinFsp 最核心也最容易被忽略的机制——IPC（进程间通信，即用户态和内核态之间传递请求的通道）。

想象你在网上寄快递：应用层把"写入 4KB 数据"这张快递单交给内核，内核驱动不是傻等你的程序签收，而是把单子丢进队列、立刻回一句"已收件"，然后接着处理下一单——这就是异步。你的程序从队列里取单、处理、回执，整条流水线并行运转，而不是每来一个请求就阻塞全局。文档 WinFsp-as-an-IPC-Mechanism.asciidoc 里的时序图画得很清楚：

一次 WriteFile 从用户态到文件系统实现，再回到调用者的完整旅程

支撑这套异步流水线的底层，是一个叫Queued Events（队列事件）的同步原语——文档 Queued-Events.asciidoc 用状态转换图讲透了它：

事件在"非信号态/已信号态"之间切换，驱动着整个请求队列高效流转

这一步为什么关键？因为 IPC 效率直接决定文件系统性能。Windows 下用户态与内核态切换开销巨大，WinFsp 靠"队列化 + 批量处理"把每次切换的成本摊薄，这正是它性能能逼近甚至反超 NTFS 的底气。

实战进阶：从零写一个能"转发"的最小文件系统

理论够了，动手。最简单也最实用的练手项目是passthrough（透传）：把虚拟路径映射到本地真实目录，所有读写原样转发，等于给一个文件夹"开了一个盘符"。示例源码 只有几百行，核心思路就两个函数：

#include <fuse.h> // 把虚拟路径拼成真实路径，直接查询本地文件属性 static int ptfs_getattr(const char *path, struct fuse_stat *stbuf) { return -1 != lstat(path, stbuf) ? 0 : -errno; } // 注册一组操作回调：getattr / read / write / mkdir ... static struct fuse_operations ptfs_ops = { .getattr = ptfs_getattr, .read = ptfs_read, // 转发 read .write = ptfs_write, // 转发 write .mkdir = ptfs_mkdir, // 转发 mkdir }; int main(int argc, char *argv[]) { return fuse_main(argc, argv, &ptfs_ops, NULL); }

注意这里用的是 WinFsp 提供的 FUSE API（inc/fuse/），如果你在 Linux 上写过 FUSE 文件系统，几乎可以无缝迁移。编译后执行：

passthrough-fuse.exe --VolumePrefix=\passthrough C:\some\real\dir net use Z: \\passthrough

现在 Z 盘就是对C:\some\real\dir的实时镜像。把 getattr 换成从数据库或对象存储读数据——你的"云盘本地盘"就诞生了。

避坑清单：新手最容易踩的 6 个坑

上手快不代表没坑。这 6 个坑提前帮你踩平：

每个坑背后都有对应文档，出问题时先翻 WinFsp-Design.asciidoc，缓存与生命周期设计都讲透了。

选型建议：什么时候该用 WinFsp，什么时候该换

性能是开发者最关心的问题。官方测试文档 WinFsp-Performance-Testing.asciidoc 用 MEMFS 与 NTFS 做了对比，下面是文件操作测试（柱子越短越好）：

MEMFS 的 create 耗时约为 NTFS 的三分之一，多数操作打平或反超

这是"内存盘 vs 磁盘"的不公平对决，但它证明了一件事：用户态文件系统的 IPC 开销远没有想象中大。那么在什么场景下应该换掉 WinFsp？

• 需要断电恢复与强一致性的数据：请用真实文件系统（NTFS/ReFS），WinFsp 不做也不该做这件事；
• 必须内核级极限性能且预算充足：可评估 WinFsp-Kernel-Mode-File-Systems.asciidoc 描述的内核模式开发方案；
• 只想快速给文件夹加个盘符：Dokan 等替代品可选，但 WinFsp 在稳定性、API 丰富度（原生 + FUSE2/FUSE3 + .NET）上优势明显。

一句话结论：当你的数据源是"软件"而不是"磁盘"时，WinFsp 就是正确选择。

下一步：照着这份路线图动手

现在是时候从"看懂"走向"做出来"了，给你一条清晰的 4 步路线：

1. 今天：跑通 MEMFS 挂载，亲身体会"盘符就是我的程序"的感觉；
2. 本周：把 tst/memfs/ 或 tst/passthrough-fuse/ 改造成你自己的文件系统骨架；
3. 本月：精读 WinFsp-as-an-IPC-Mechanism.asciidoc，吃透队列与异步模型，为高并发做准备；
4. 进阶：跑一遍 tst/winfsp-tests/ 测试套件，用官方测试兜底你的实现正确性。

WinFsp 最迷人的地方在于：它把"造一个磁盘"从内核特权阶级的专利，变成了普通开发者的日常。你的数据在数据库里、在云端、在内存里——现在它们都可以是一个盘符。动手吧，从你的第一个 X 盘开始。

【免费下载链接】winfspWindows File System Proxy - FUSE for Windows项目地址: https://gitcode.com/gh_mirrors/wi/winfsp