最稳配置是wsl2中用nvm安装node.js（非apt），再通过vscode remote-wsl扩展连接，项目文件须存于wsl文件系统（如/home/user/projects），禁放/mnt/c/；验证node/npm版本匹配，launch.json中runtimeexecutable需写死which node路径。
直接在 WSL 2 中安装 Node.js，再用 VSCode 的 Remote - WSL 扩展连接进去——这是最稳、最贴近生产环境的配置方式。其他方式（比如复用 Windows 的 Node 或硬 symlinks）容易出 module not found、spawn ENOENT 或权限/路径解析错误。
WSL 2 里装 Node.js 要用 nvm，别用 apt install nodejs
Ubuntu 官方源里的 nodejs 版本太老（常是 v10/v12），且 npm 不配套，后续装 pnpm 或 corepack 会报错或缺失 CLI。
- 先装
nvm：curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash，然后重启 shell 或运行source ~/.bashrc - 再装稳定版 Node：
nvm install --lts（当前是 v20.x），并设为默认：nvm alias default lts/* - 验证：
node -v和npm -v应同时输出匹配版本，且which node指向~/.nvm/versions/node/...
VSCode 必须通过 Remote - WSL 连进 WSL，不能只靠 code . 在 Windows 终端里执行
code . 命令本身没问题，但前提是它得从 WSL 终端里运行——否则 VSCode 会用 Windows 的 PATH 和 shell，导致终端里 node 可用，但调试器或任务（Tasks）找不到可执行文件。
- 打开 Ubuntu（或其他发行版）终端，cd 到项目目录，运行
code . - 或者在 VSCode 命令面板（
Ctrl+Shift+P）中输入Remote-WSL: New Window，再用文件浏览器打开 WSL 路径下的项目 - 确认左下角状态栏显示
WSL: Ubuntu（或你用的发行版名），而不是Local
项目文件必须放在 WSL 文件系统里，别放 /mnt/c/...
放在 /mnt/c 下会导致 npm install 极慢、symlink 权限错误、Git hooks 失效，甚至某些 native addon 编译失败——因为 Windows NTFS 对 Linux 的 uid/gid、exec bit、symbolic link 支持不完整。
- 推荐路径：
/home/用户名/projects/my-app - 如果非要从 Windows 访问，用
explorer.exe .在 WSL 终端里执行，它会自动映射到 Windows 文件资源管理器 -
npm install后检查node_modules/.bin里的二进制是否可执行：ls -l node_modules/.bin/eslint，应有x权限；若显示??????????，说明路径挂载有问题
launch.json 调试配置要显式指定 runtimeExecutable
VSCode 默认找 node 在 PATH 里，但在 Remote-WSL 场景下，PATH 是 WSL 的，而调试器有时仍会尝试用 Windows 的解析逻辑，导致断点不触发或报 Cannot launch program ... because corresponding JavaScript file cannot be found。
- 在项目根目录建
.vscode/launch.json，关键字段写死路径："runtimeExecutable": "/home/用户名/.nvm/versions/node/v20.18.0/bin/node"（用which node输出为准） - 避免用
env注入变量来改NODE_OPTIONS，WSL 环境下某些选项（如--inspect）需由调试器自己加，手动加反而冲突 - 启动调试前，确保终端里
node --version和launch.json里写的路径指向同一版本
真正麻烦的不是装软件，而是文件系统边界和进程上下文切换——WSL 里跑的 node 进程，和 VSCode 里启动它的调试器，必须共享同一套 uid、PATH、fs 权限模型。跨过这个边界时，任何“差不多就行”的路径或环境假设，都会在 npm run dev 卡住三秒后突然报错。
