必须将项目移至wsl2原生路径（如~/myapp）并用code .在wsl终端启动，因/mnt/c/路径走9p协议导致高频小文件i/o延迟高达300–500ms/次，而原生ext4路径可彻底规避该瓶颈。
直接结论：跨文件系统执行代码卡顿，不是 VSCode 或 WSL2 的配置问题，而是 9P 协议在高频小文件 I/O 场景下的固有延迟——必须把项目挪到 WSL2 原生路径（如 ~/myapp），并用 code . 在 WSL 终端里启动。
为什么 code /mnt/c/xxx 会慢得像卡住
VSCode 启动时若指向 /mnt/c/ 下的路径，实际走的是 WSL2 的 9P 文件协议桥接层。这不是“慢一点”，而是对 node_modules、package.json、.git 这类小文件密集型操作，I/O 延迟常达 300–500ms/次。npm install 卡住、tsc --watch 响应滞后、热重载失灵，根源都在这里。
- 9P 是网络模拟协议，不是本地文件系统，每次
stat、open、read都要穿越虚拟化层和 Windows 安全子系统 -
files.watcherExclude对跨系统路径无效——VSCode 的监听器仍会尝试注册 inotify 句柄，但底层根本无法高效响应 - Remote-WSL 插件不会自动绕过这个路径陷阱；它只在你从 WSL 内启动
code时才真正接管
怎么确认你正踩在 9P 坑里
打开 WSL2 终端，进入你的项目目录，运行：
df -T .
如果输出中 Type 列显示 9p，说明当前路径位于 Windows 挂载区（比如 /mnt/c/Users/xxx/project）；如果显示 ext4，才是 WSL2 原生磁盘。
- 别信资源管理器里看到的
\wsl$Ubuntuhomexxx路径——那是 Windows 端映射，编辑器走的仍是 9P -
wslpath -m .返回/mnt/c/...就是危险信号 - 终端里执行
npm start明显卡顿，但ls node_modules | head -n 5也明显延迟，基本可锁定为 9P 问题
迁移项目到 WSL2 原生路径的实操步骤
别复制粘贴整个 node_modules——用 cp -r 会触发海量 9P 写入，极慢。正确做法是：先搬源码，再重装依赖。
- 在 WSL2 中创建目标目录：
mkdir -p ~/projects/myapp - 仅复制源码和配置文件（避开
node_modules、dist、.next等构建产物）：cp -r /mnt/c/Users/xxx/myapp/{src,public,package.json,tsconfig.json,.gitignore} ~/projects/myapp/ - 进入新路径：
cd ~/projects/myapp - 重装依赖：
npm install（此时node_modules直接落在 ext4 上，速度正常） - 启动 VSCode：
code .（确保已安装 Remote-WSL 插件，且没启用remote.WSL.useWslPreview）
容易被忽略的三个细节
改完路径后关掉所有 Windows 版 VSCode 窗口——残留进程可能继续监听旧路径，导致文件监视器冲突；node_modules 必须在 WSL2 内生成，不能从 Windows 复制；.vscode/settings.json 里的 files.watcherExclude 要配在工作区级，且至少包含 "**/node_modules/**": true 和 "**/.git/**": true，否则即使路径对了，CPU 也会被 chokidar 拖垮。
