必须在WSL终端中执行code .才能真正接入WSL：启动上下文决定环境，状态栏显示“WSL: Ubuntu”为唯一可信凭证，项目须置于/mnt/c外的原生路径（如/home/user/），否则chmod、git hooks、调试器等功能异常。
code . 必须在 WSL 终端里执行
VSCode 不靠路径判断是否接入 WSL，只认启动进程的上下文。你在 Windows 的 PowerShell 或资源管理器里双击打开 /home/user/project，哪怕路径看起来是 Linux 风格，后端仍跑在 Windows 上——chmod 静默失败、git commit 不触发 hooks、node_modules 权限混乱，全由此而起。
真正生效的方式只有一种：先在 WSL 终端（如 Ubuntu）中 cd 到项目目录，再运行 code .。这会触发 Remote-WSL 自动下载 vscode-server 到 ~/.vscode-server，并新建一个窗口。
- 确认 WSL 已运行：
wsl -l -v显示状态为Running；若为Stopped，先执行wsl -d Ubuntu（替换为你实际发行版名） - 确保
code命令可用：在 Windows 端 VSCode 中按Ctrl+Shift+P→ 输入Shell Command: Install 'code' command in PATH→ 执行 → 重启 WSL（wsl --shutdown） - 如果
which code报错，手动加一行到~/.bashrc：export PATH="$PATH:/mnt/c/Users/xxx/AppData/Local/Programs/Microsoft VS Code/bin"（路径按你实际安装位置调整）
项目必须放在 WSL 原生路径下
/mnt/c/ 是 Windows 文件系统的挂载点，WSL2 对它的 I/O 性能差，且调试器（如 gdb、lldb）无法正确加载符号表——断点不命中、Unable to start debugging. Unexpected GDB output 就是典型表现。
所有开发行为（编译、调试、git、chmod）都要求项目路径在 WSL 根文件系统内，例如：/home/user/myapp。
- 已有项目在
/mnt/c/Users/xxx/project？用cp -r /mnt/c/Users/xxx/project ~/project复制过去再code . - 别把项目放
C:\再通过/mnt/c/访问——这不是“跨系统协作”，是主动给自己埋雷 - VSCode 状态栏左下角显示绿色
WSL: Ubuntu（或你发行版名）才算真正接入；显示Windows或无标识，说明仍是本地模式
终端 Ctrl+C 不生效？换 bash
在 VSCode 集成终端中运行 python main.py 或 npm run dev 时，Ctrl+C 频繁失效，不是你的代码问题，而是 WSL2 + VSCode 在 zsh 下对 SIGINT 信号转发不稳定。
这不是 shell 配置能修好的，属于环境层缺陷。
- 在 VSCode 设置中搜索：
terminal.integrated.defaultProfile.linux - 将其值改为
bash（或你发行版对应的默认 profile，如Ubuntu-22.04） - 关闭当前终端，按
Ctrl+Shift+`新建一个，确认提示符变成user@hostname:~$ - 别折腾
stty或trap，这类修复无效
command 'remote-wsl.reopenInWsl' not found 怎么办
这个报错不是插件没装，而是 VSCode 根本没检测到可用的 WSL2 发行版——常见于安装后从未手动启动过发行版，或默认发行版名字不在 Remote-WSL 白名单内（比如叫 Ubuntu-24.04 而非 Ubuntu）。
- 运行
wsl -l -v，看是否有发行版状态为Running - 若显示
Stopped，执行wsl --set-default Ubuntu（替换为你实际发行版名） - 若发行版名含后缀（如
Ubuntu-22.04-custom），用wsl --set-default Ubuntu-22.04重设默认 - 确认你装的是官网版 VSCode（
VSCodeUserSetup-x64.exe），Microsoft Store 版因权限受限，Remote-WSL 功能不可靠
最常被忽略的点：WSL 接入不是“打开路径”，而是“启动上下文”。一切功能（调试、权限、hooks、路径语义）都依赖这个上下文是否真实成立。状态栏那个绿色图标，不是装饰，是唯一可信的凭证。
