VSCode连接WSL必须从WSL终端执行code .，而非Windows中启动；项目须存于WSL原生路径（如/home/username/project），不可放/mnt/c/；状态栏显示“WSL: Ubuntu”才表示成功接入，否则调试、权限、git等功能均失效。
VSCode 连接 WSL 不是“连接虚拟机”，而是直接复用 WSL2 的轻量级虚拟化环境——它没有传统意义上的 SSH 配置、IP 地址或端口映射，靠的是 VSCode 原生集成的 Remote-WSL 扩展和正确的启动入口。错用启动方式（比如在 Windows PowerShell 里执行 code .）会导致看似打开了 Linux 路径，实则仍在 Windows 进程里操作，所有权限、调试、git hooks 全部失效。
必须从 WSL 终端执行 code .
这是唯一可靠、官方支持的接入方式。VSCode 不靠路径判断是否进 WSL，只认启动进程的上下文。
- 先确保 WSL 已运行：
wsl -l -v看状态是否为Running；若不是，用wsl -d Ubuntu（替换为你实际发行版名）手动启动 - 在 WSL 终端中
cd到项目目录，例如：cd ~/projects/myapp - 执行：
code .—— 这会触发 VSCode 自动下载vscode-server到~/.vscode-server，并新建窗口 - 检查左下角状态栏：出现绿色
WSL: Ubuntu（或你发行版名）标识才算成功；若显示Windows或无标识，说明仍是本地模式
/mnt/c/ 下的项目无法正常调试和设断点
WSL2 的调试器（如 gdb、lldb）无法正确加载 /mnt/c/ 路径下的可执行文件，符号表读取失败、断点不命中是常态。这不是配置问题，是 WSL2 文件系统桥接层的限制。
直播话术巡检系统(Windows版) — 实时语音转写、关键词检测、场景自动切换、告警推送、大屏可视化。支持 Windows VB-Cable 虚拟声卡音频采集，阿里云 ASR 实时识别。一键启动脚本，自动安装环境。
- 项目代码必须放在 WSL 原生路径下，例如：
/home/username/project - 避免把项目放 Windows 盘（
C:\）再通过/mnt/c/xxx访问——I/O 性能差，且调试、chmod、git权限全不可靠 - 如果已有项目在
/mnt/c/，用cp -r /mnt/c/Users/xxx/project ~/project复制到 home 目录后再code .
终端 Ctrl+C 不生效？换 bash，别用 zsh
这是 WSL2 + VSCode 集成终端的信号转发缺陷，在 zsh 下高频出现，尤其对 python main.py 或 npm run dev 这类长期运行进程。不是你的代码问题，是环境层对 SIGINT 处理不稳定。
- 在 VSCode 设置中搜索：
terminal.integrated.defaultProfile.linux - 将其值改为
bash（或你 WSL 发行版对应的 bash profile，如Ubuntu-22.04） - 关闭当前终端，按
Ctrl+Shift+`新建一个，确认提示符变成user@hostname:~$ - 别折腾
stty或 shell 层的trap，这类修复无效
command 'remote-wsl.reopenInWsl' not found 错误怎么解
这个报错不是插件没装，而是 VSCode 根本没检测到可用的 WSL2 发行版——常见于安装后从未手动启动过发行版，或默认发行版名字不在 Remote-WSL 白名单内（如叫 Ubuntu-24.04 而非 Ubuntu）。
- 在 PowerShell 中运行：
wsl -l -v，确认发行版状态为Running，名称是Ubuntu、Debian等标准名 - 如果不是，用：
wsl --set-default Ubuntu（替换成你实际发行版名）设为默认 - 确保已安装官方扩展：
ms-vscode-remote.remote-wsl（ID），且未被工作区禁用 - 关掉所有 VSCode 窗口，**不要**在 VSCode 里按
Ctrl+P输命令，而是回到 WSL 终端重新执行code .
最常被忽略的点：WSL2 内核需要单独更新，uname -r 输出低于 5.10 可能导致 dockerd 启动失败、Python 调试器找不到解释器等连锁问题。别等 Windows Update，去微软官网下 wsl_update_x64.msi 手动装。
