因为 /mnt/c/ 下文件操作需经 9p 协议跨虚拟机边界，每次 i/o 延迟达 200–500ms；应将项目移至 ~/projects（ext4 原生路径），并在 wsl2 终端中执行 code .，确保状态栏显示“wsl: ubuntu”且 remote-wsl 扩展已激活。
为什么 code . 在 /mnt/c/ 下启动就卡
因为 VSCode 通过 Remote-WSL 打开项目时，若路径落在 /mnt/c/（或 /mnt/d/ 等），所有文件操作都经由 9P 协议转发到 Windows 主机——每次 stat、open、read 都要穿越虚拟机边界，小文件密集场景（如 node_modules 加载、TypeScript 类型检查）延迟直接拉到 200–500ms。这不是 VSCode 的 bug，是架构使然。
-
df -T .输出含9p，说明当前目录走跨系统协议；输出为ext4才是 WSL2 原生路径 - 别指望“优化 9P 参数”能治本——
trans=fd和version=9p2000.L已是微软调优后的默认值 - Windows 资源管理器里看到的
\wsl$Ubuntuhomeuserproject是只读映射，写入仍走 9P，不解决根本问题
把项目挪到 ~/projects 后，code . 还没反应？
常见原因是没真正触发 Remote-WSL 模式——VSCode 可能仍在 Windows 端本地打开，而非连接 WSL2 实例。确认方式：左下角状态栏应显示 WSL: Ubuntu（或你的发行版名），而不是 Local。
- 必须在 WSL2 终端内执行
code .，不能在 Windows PowerShell 或 CMD 里运行 - 确保已安装 Remote-WSL 扩展，并重启过 VSCode（仅启用扩展不够，需重载窗口）
- 首次运行时会自动安装 VS Code Server 到
~/.vscode-server，若失败可手动清理：rm -rf ~/.vscode-server再试 - 如果 WSL2 实例长期未关，
wsl --shutdown后再启动，避免旧服务进程残留
files.watcherExclude 设了却还是慢？
VSCode 的文件监视器（file watcher）默认用 inotify 监控变更，但在 WSL2 中，inotify 对挂载路径（/mnt/c/）支持有限，且即使排除了 node_modules，语言服务器（如 TypeScript Server）仍可能主动扫描整个工作区——尤其当 tsconfig.json 里用了 "include": ["**/*"]。
- 除了
files.watcherExclude，务必同步配置search.exclude和typescript.preferences.includePackageJsonAutoImports为"auto"（减少包解析压力） - 在
.vscode/settings.json中加："typescript.preferences.disableAutomaticTypeAcquisition": true，禁用后台自动获取 @types - 检查
code --status输出里的 “Extensions” 区域，确认 Remote-WSL 是 active 状态，而非被其他远程扩展（如 SSH）抢占
.wslconfig 调了内存但没效果？
WSL2 资源限制只对新启动的实例生效，且配置文件位置必须严格为 C:Users\.wslconfig（不是 WSL2 里的 home 目录）。常见失效原因：路径错、没重启、或被企业策略拦截。
- 配置示例必须顶格写，无空行、无 BOM：
[wsl2] memory=6GB processors=4 swap=2GB
- 修改后必须执行
wsl --shutdown（PowerShell 或 CMD），再打开任意 WSL2 终端才加载新配置 - 验证是否生效：
cat /proc/meminfo | grep MemTotal应接近设置值；nproc应返回设定的核心数 - 若仍卡顿，检查 Windows Defender 是否在扫描
%LOCALAPPDATA%Packages下的 WSL2 包目录——添加wsl.exe和对应发行版路径（如Ubuntu_…文件夹）到排除列表
code 命令还在 Windows 环境里执行。性能优化的第一步，永远是验证你正在操作的那个“环境”，到底是不是你以为的那个。
