必须通过remote-wsl插件启动vscode并打开wsl原生路径（如/home/user/myapp），确保进程、终端、tasks.json、launch.json全部运行于wsl2环境，项目严禁放在/mnt/c下。
VSCode 要真正用上 WSL2 的 Linux 环境，不是“连得上”就行，而是必须让整个编辑器进程、终端、任务、调试器全部落在 WSL2 里——否则 which git 返回 C:Program FilesGitingit.exe，python 指向 Windows Python，npm run build 直接报 command not found，全是幻觉式“连通”。
Remote-WSL 插件启动方式决定一切
VSCode 必须通过 Remote-WSL 插件启动，而不是在 Windows 下打开 wsl$Ubuntuhomeuserproject 这类路径。后者只是把 Windows 文件资源管理器的映射路径扔给 VSCode，它仍在 Windows 进程中运行。
- 正确流程：Windows 启动 VSCode（不打开任何文件夹）→
Ctrl+Shift+P→ 输入WSL: New Window→ 选发行版（如Ubuntu-22.04）→ 再用File → Open Folder…打开/home/user/myapp - 验证是否成功：状态栏左下角显示
WSL: Ubuntu-22.04，新建终端自动是bash，且echo $PATH不含C:盘路径 - 常见错误：右键
wsl$路径 → “用 Code 打开”，这等于欺骗自己——VSCode 根本没进 WSL，tasks.json和launch.json仍按 Windows 环境解析
tasks.json 和 launch.json 必须适配 WSL 路径语义
即使终端显示的是 bash，VSCode 的构建任务和调试器默认不继承终端环境变量，尤其当配置中出现 Windows 风格路径或未声明 shell 类型时，会静默 fallback 到 Windows 工具链。
-
tasks.json中必须设"type": "shell"，命令写"npm install"即可，不要写完整路径；避免出现C:\Users\xxx或cmd /c类字段 -
launch.json的python.defaultInterpreterPath必须是 WSL 内部路径，例如/home/user/.pyenv/versions/3.11.9/bin/python，不能是C:Users...python.exe - 若使用
preLaunchTask，确认该 task 的"group"是"build"，且"isBackground": true配合正确的problemMatcher，否则调试器卡在“正在启动”
绝对不要把项目放 /mnt/c 下
/mnt/c/Users/xxx/project 看似方便同步，实为权限、git、性能三重陷阱区：WSL2 对 /mnt/c 下文件的 chmod 是模拟的，git 会因执行位（x-bit）频繁误判为“已修改”，git status 总显示一堆无关变更；同时 Node.js 的 fs.watch 在该路径下极不稳定，热重载常失效。
- 项目根目录应严格放在 WSL2 原生文件系统内，如
/home/user/src/rv1106-firmware - 如需访问 Windows 文件（比如文档、设计图），用
/mnt/c/Users/xxx/Documents作只读挂载，不参与构建或版本控制 - 交叉编译工具链（如
arm-linux-gnueabihf-gcc）也必须安装在 WSL2 原生路径，且PATH添加到~/.bashrc，再source ~/.bashrc
最易被忽略的一点：WSL2 发行版是 per-user 安装的，不同 Windows 用户账号下的 Ubuntu 是完全隔离的。如果你用管理员账户装了 Ubuntu，但日常登录是标准用户，wsl -l -v 可能看不到它，或者 WSL: New Window 里选不到——此时需要在标准用户下重新运行 wsl --install 或手动导入分发版。
