Windows 上用 WSL 开发文件性能问题

FreeGuideOnline 最新 2026-07-04

bash

假设你有一个包含许多小文件的 node_modules 目录，或创建一个测试目录

mkdir ~/linux-test cd ~/linux-test

生成 1000 个小文件

for i in $(seq 1 1000); do echo "test$i" > file$i.txt; done

测试 Linux 原生文件系统的删除速度

time rm -rf ~/linux-test

在 /mnt/c 下重复相同操作（确保目录不存在）

mkdir /mnt/c/win-test cd /mnt/c/win-test for i in $(seq 1 1000); do echo "test$i" > file$i.txt; done

测试跨文件系统删除速度

time rm -rf /mnt/c/win-test


你会看到 Linux 原生路径的完成时间通常在毫秒级，而 `/mnt/c` 可能需要数秒甚至更久。

### 测试 2：使用专业工具测量 IOPS

安装 `fio` 可以更精确地测量每秒钟输入输出操作次数。

```bash
sudo apt update && sudo apt install fio -y

# 测试 ~/ 下的随机读写（Linux 文件系统）
fio --name=random-rw --ioengine=libaio --direct=1 --bs=4k --size=100M --rw=randrw --rwmixread=70 --filename=/home/$(whoami)/fio_test

# 测试 /mnt/c 下的随机读写
fio --name=random-rw --ioengine=libaio --direct=1 --bs=4k --size=100M --rw=randrw --rwmixread=70 --filename=/mnt/c/fio_test

两种场景下的 IOPS 差距可能达到 数十倍甚至上百倍。

优化方案：把文件性能“拉回”正常水平

以下是按推荐度排序的实战方案，你可以根据自己必须的协作需求选用其中一种或组合使用。

方案一：将项目文件完全放在 WSL 的 Linux 文件系统中（强烈推荐）

这是最彻底、最简单的解决方法。WSL 的 Linux 文件系统（ext4 格式）提供原生的高性能 I/O，没有跨系统开销。

操作步骤：

  1. 在 WSL 终端中进入你的 Linux 家目录： 
    cd ~
  2. 在此处创建项目目录并克隆或移动代码： 
    mkdir projects
cd projects
git clone <your-repo-url>
  3. 所有日常工作（编辑代码、运行构建、测试）都在这个路径下完成。

如何从 Windows 中访问这些文件？
在 Windows 资源管理器地址栏输入 \\wsl$\<你的发行版名称>（例如 \\wsl$\Ubuntu-22.04\home\user\projects），即可像操作普通文件夹一样浏览和编辑。你也可以在 VS Code 中通过 Remote - WSL 扩展直接在 WSL 环境内打开项目。

优势： 获得与原生 Linux 几乎一致的性能。
注意事项： 不要从 Windows 应用程序直接操作 \\wsl$\ 下的文件来编译或运行 Linux 命令，否则又会引入跨系统开销。

方案二：使用 VS Code Remote - WSL 扩展（零成本集成）

如果你习惯用 VS Code，这个方案可以让你“感觉”项目仍在 Windows 上，但实际运行环境完全是 WSL。

  1. 安装 Remote - WSL 扩展。
  2. 在 WSL 终端中，进入项目目录并输入 code .。VS Code 会自动在 WSL 中启动一个远程会话。
  3. 此时你的代码文件存储在 WSL 的 Linux 文件系统内（~/...），而 VS Code 的用户界面依旧运行在 Windows 上。终端、任务、调试器全部在 WSL 中执行，享受原生 I/O 速度。

这完美解决了 “想从 Windows 启动编辑器，但需要 Linux 运行环境” 的矛盾。

方案三：优化 WSL 2 的 Windows 挂载性能（适用于必须使用 /mnt/c 的场景）

如果你由于某些原因（如与 Windows 端工具深度绑定）必须将代码存放在 /mnt/c 下，可以通过调整挂载配置来减少一部分性能损失。

编辑 /etc/wsl.conf（如果文件不存在则新建），加入以下内容：

[automount]
enabled = true
options = "metadata,umask=22,fmask=11,case=off"

参数解释：

  • metadata：允许 Linux 权限、所有者等元数据在 Windows 驱动器上生效（需小心，可能略增延迟）。
  • umask=22,fmask=11：调整文件和目录权限，避免不必要的权限检查。
  • case=off：关闭大小写敏感检查，NTFS 默认大小写不敏感，关闭后减少转换开销。

修改后重启 WSL：

wsl --shutdown

然后重新打开终端。

实测效果： 可以部分改善小文件操作的延迟，但不可能达到 Linux 原生文件系统的水平。对 npm install 这类海量 I/O 场景仍有明显卡顿。

方案四：换用 WSL 1（适用于不依赖 Docker 等高级功能的项目）

WSL 1 对 Windows 文件系统的访问是直接通过 NTFS 驱动实现的，在 /mnt/c 下的操作比 WSL 2 快得多。如果你不需要完整的 Linux 内核（例如只运行 Node.js、Python、Ruby），WSL 1 可能更适合跨文件系统开发。

转换版本：

wsl --set-version <发行版名称> 1

（用 wsl -l -v 查看发行版名称）

权衡：

  • WSL 1 不支持 Docker、systemd、snap 等需要真实内核的功能。
  • 文件性能在选择 Linux 原生文件系统时，WSL 2 依然优于 WSL 1。

如果是混合开发（既有大量 Windows 交互又需要高性能），亦可安装两个发行版：一个 WSL 2 用于项目运行，一个 WSL 1 用于快速访问 Windows 文件。

方案五：将重型依赖缓存放到 Linux 文件系统

对于不完全符合方案一的情况，可以只将 I/O 密集型部分移入 Linux 分区。以 Node.js 项目为例，把 node_modules 放在 WSL 的 Linux 文件系统中，而源代码仍留在 /mnt/c 下。

# 在 WSL 的 Linux 家目录中创建 node_modules 目录
mkdir -p ~/deps/node_modules

# 在项目根目录（位于 /mnt/c/...）创建符号链接
ln -s ~/deps/node_modules node_modules