WSL中code命令失效需手动执行code --install-server；调试路径错乱需配置sourceFileMap；权限问题应避免/mnt/c开发并启用metadata支持；必须使用WSL2而非WSL1。
WSL开发环境没连上，code 命令打不开VSCode？
不是 VSCode 没装好，是 WSL 里根本没装 code 命令行工具。它不像 Windows 那样自动注册 PATH，得手动在 WSL 终端里运行一次安装脚本。
- 先确保 Windows 端 VSCode 已安装（带 WSL 支持），且 WSL 发行版已更新到较新内核（如 Ubuntu 22.04+）
- 在 WSL 终端里执行：
code --install-server（仅首次需要） - 之后用
code .才能真正打开当前目录，且工作区会以 WSL 路径为准（比如/home/user/project） - 如果提示
command not found: code，说明没装或装错位置——别用sudo apt install code，那是第三方包，不兼容 WSL 远程
终端里 gcc 正常但 VSCode 报 cannot find -lc
这是 WSL 的 libc 路径没被 VSCode 的 C/C++ 扩展识别，不是编译器问题，而是 IntelliSense 和链接器配置脱节。
- 检查
c_cpp_properties.json中的includePath是否包含/usr/include/**和/usr/lib/gcc/** - 确保
compilerPath指向 WSL 下的真实路径，例如/usr/bin/gcc，而不是 Windows 的gcc.exe - 别依赖默认配置：WSL 扩展启动时不会自动读取 shell 的
PATH或LD_LIBRARY_PATH，所有路径必须显式写死或用变量${env:HOME} - 如果用了
clangd，记得在 WSL 里单独sudo apt install clangd，VSCode 不会帮你装语言服务器
调试时断点不命中，launch.json 总是 fallback 到 Windows 路径
VSCode 在 WSL 模式下仍可能把源码路径解析成 Windows 格式（C:Users...），导致调试器找不到对应文件。
- 在
launch.json中强制指定sourceFileMap，把 Windows 路径映射回 WSL： "sourceFileMap": { "C:\": "/mnt/c/", "D:\": "/mnt/d/" }- 确保可执行文件是用 WSL 的
gcc -g编译的，Windows 子系统下生成的二进制不带调试符号或路径信息错乱 - 如果项目含子模块或 symlink，检查
cwd是否指向 WSL 原生路径（/home/xxx/...），而非/mnt/wsl/...这类挂载伪路径
文件保存后 Linux 权限变乱，chmod 失效
Windows 文件系统（NTFS）本身不支持 Unix 权限，WSL 默认把 /mnt/c 下的文件全当 755 处理，但 VSCode 通过远程插件保存时可能触发权限重置。
- 只在 WSL 原生文件系统（
/home、/tmp）中开发，避免把项目放/mnt/c/Users/... - 如果必须跨挂载点编辑，启用 WSL 的 metadata 支持：在
/etc/wsl.conf加入[automount] options = "metadata"，然后重启 WSL（wsl --shutdown） - VSCode 设置里关掉
files.autoGuessEncoding和files.eol自动探测，它们有时会触发冗余保存，间接影响 inode 属性
最麻烦的其实是 WSL 版本混用：WSL1 没有真正的 Linux 内核，chown、setuid 类操作全靠模拟，VSCode 的文件监听和调试器都可能卡在这种边界上。真要用权限敏感功能，只认 WSL2。
