VSCode快捷键有效前提是已正确进入WSL上下文：必须通过Ctrl+Shift+P执行Remote-WSL: New Window，确保右下角显示WSL: Ubuntu且终端提示符为username@hostname:~$，否则所有快捷键仍运行于Windows环境。
VSCode快捷键本身不“适配”WSL，真正起作用的是你是否已进入WSL上下文——所有快捷键（包括Ctrl+`、Ctrl+Shift+P、F5）只有在正确加载WSL环境后，才调用Linux工具链、读写Linux路径、触发Linux调试器。
按Ctrl+Shift+P后找不到Remote-WSL: New Window
这不是快捷键失效，而是Remote - WSL扩展未启用或VSCode未识别到已安装的WSL发行版。
- 先确认WSL已成功运行：
wsl -l -v输出中状态必须是Running，且版本为2 - 检查VSCode是否为Windows原生安装版（不是WSL里
apt install code装的），且Remote - WSL扩展处于启用状态（非灰色/禁用） - 若仍不出现该命令，重启VSCode并确保以管理员权限启动过一次PowerShell执行过
wsl --update
Ctrl+`打开的终端还是PowerShell/CMD
说明当前VSCode窗口根本没连上WSL——它只是个普通Windows窗口，快捷键自然调不出Linux终端。
- 不要通过“Open Folder…”直接选
/mnt/c/...路径，这强制以Windows模式打开 - 正确做法：先按
Ctrl+Shift+P→ 输入Remote-WSL: New Window→ 等待新窗口右下角明确显示WSL: Ubuntu（或你的发行版名） - 此时再按
Ctrl+`，提示符才会变成username@hostname:~$，且which python3返回/usr/bin/python3而非/mnt/c/...
按F5调试C/C++时提示Cannot find gdb
VSCode调试器依赖PATH查找可执行文件，但它不会加载.bashrc里的export PATH=...，更不会识别alias。
- 确保
gdb已通过sudo apt install gdb装在WSL里，且which gdb返回有效路径 - 在VSCode的
launch.json中显式指定"miDebuggerPath": "/usr/bin/gdb"，别依赖自动发现 - 如果用了自定义shell（如zsh），需在WSL的
~/.profile中导出PATH（.bashrc在非交互式场景下不被读取）
跨系统联调时localhost访问不到WSL服务
WSL2默认使用虚拟网络，其localhost与Windows主机localhost不互通，这是设计使然，不是bug。
- 从Windows浏览器访问WSL服务，用
http://localhost:3000（前提是WSL中服务监听0.0.0.0:3000，而非127.0.0.1:3000） - 从WSL访问Windows服务（如本地MySQL），用
host.docker.internal或$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}')获取Windows主机IP - 若端口被占用或防火墙拦截，临时关闭Windows Defender防火墙或运行
netsh interface portproxy add v4tov4 listenport=3000 listenaddress=127.0.0.1 connectport=3000 connectaddress=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}')
最常被忽略的细节是：WSL文件系统路径（/home/xxx/...）和Windows路径（/mnt/c/...）混用一次，就可能让Git、npm、make全部报错；而这些错误从表面看跟快捷键毫无关系，实际根源却是环境没切对——快捷键只是暴露问题的开关，不是问题本身。
