必须在wsl终端执行code .才能真正接入remote-wsl，否则操作仍在windows层运行，导致权限、git hooks、调试等功能异常；正确流程是cd项目目录后执行code .，左下角出现绿色wsl图标即成功。
能，但必须用 code . 在 WSL 终端里启动，否则只是“看起来像”，实际所有操作仍在 Windows 上跑。
为什么 code . 必须在 WSL 里执行
VSCode 的 Remote-WSL 插件不是靠路径识别是否接入 WSL，而是靠启动入口。Windows 版 VSCode 进程默认运行在 Windows 用户空间，即使你打开的是 /home/user/project 这样的路径，只要没通过 WSL 启动，它就仍走 Windows 文件系统层——chmod 失效、git hooks 不触发、node_modules 权限混乱全由此而起。
正确流程只有这一种：
- 先在 Ubuntu 终端中
cd ~/projects/myapp - 再执行
code .（确保已安装code命令：运行sudo apt install code或按 VSCode 官方文档配置 server） - 新窗口左下角出现绿色 WSL 图标，终端提示符变成
user@hostname:~$，才算真正接入
Remote-WSL: New Window 命令有时不生效的真正原因
这个命令依赖 VSCode 能检测到一个“可用且正在运行”的 WSL2 发行版。常见失效场景不是插件没装，而是：
-
wsl -l -v显示状态为Stopped—— 很可能是 WSL2 内核过旧，需手动下载安装wsl_update_x64.msi - 发行版名称不是
Ubuntu或Debian（比如叫Ubuntu-22.04-custom），Remote-WSL 默认只扫描白名单名 - 未设默认发行版：
wsl --set-default Ubuntu-22.04可修复 - 插件被工作区禁用，或 VSCode 是从 Windows 资源管理器右键打开的，根本没加载 Remote-WSL 上下文
调试 C/C++ 程序时 Unable to start debugging. Unexpected GDB output
这不是 GDB 崩了，是路径或权限错位导致的典型报错。GDB 在 WSL 里运行，但你给的 program 路径如果指向 /mnt/c/...，它会读取失败或拒绝加载。
launch.json 关键项必须严格匹配 WSL 环境：
-
"program"填绝对路径，如"/home/user/myproj/build/app"，不能是"./build/app"（相对路径在远程调试中不可靠） -
"cwd"必须是 WSL 中真实存在的目录，且当前用户有执行权限 - 确认已安装
gdb：sudo apt install gdb，别指望 Windows 的 gdb.exe 能跨系统调用 - 项目代码必须放在
/home/xxx下，/mnt/c/下的文件无法正确设置断点或读取符号表
终端里 Ctrl+C 不中断 Python 脚本
这是 WSL2 + VSCode 集成终端的信号转发缺陷，尤其在 zsh 下高频出现。bash 更稳定，不是因为功能强，而是对 SIGINT 的 pty 层处理更保守。
解决方式非常具体：
- 在 VSCode 设置中搜
terminal.integrated.defaultProfile.linux - 把它明确设为
bash（不是留空，也不是选zsh） - 重启集成终端（
Ctrl+Shift+`关闭再开），或执行Ctrl+Shift+P → Terminal: Select Default Profile → bash
别碰 stty 或 Python 里的 signal.signal() —— 这是环境层问题，改代码解决不了。
