VSCode的WSL扩展默认不支持直接编辑Windows文件，因/mnt/c/路径触发权限与路径解析冲突；正确做法是从Windows端启动VSCode并打开Windows路径，底部显示WSL标识即可复用WSL后端且避免兼容性问题。
WSL扩展默认不支持直接编辑Windows文件
VSCode 的 WSL 扩展（Remote - WSL）设计目标是把 VSCode 前端运行在 Windows 上，后端（语言服务、终端、调试器等）运行在 WSL 实例里——它默认只挂载 WSL 的根文件系统 /。Windows 文件（比如 C:Users
ameproject）虽然能通过 /mnt/c/ 访问，但直接在 VSCode 里打开 /mnt/c/Users/name/project 会触发「Windows 文件系统 + WSL 内核 + VSCode 远程协议」三者间的权限与路径解析冲突，常见表现为：文件保存失败、Git 状态异常、文件监视器（watcher）失效、fs.watch 不触发。
必须用 Windows 版 VSCode 打开 /mnt/c/... 路径
正确做法不是在 WSL 环境里“远程打开”Windows 路径，而是从 Windows 端启动 VSCode，并显式告诉它：这次要复用已运行的 WSL 后端，但工作区仍在 Windows 文件系统上。操作很简单：
- 确保已安装最新版 VSCode（Windows 版）和 Remote - WSL 扩展
- 在 Windows 文件资源管理器中，进入你的项目目录（如
C:devmyapp） - 右键空白处 → 选择
Open with Code（或命令行执行code .） - VSCode 启动后，底部状态栏会显示
WSL: Ubuntu（或你实际发行版名）——说明后端已切换到 WSL，但文件路径仍是 Windows 原生路径
此时所有编辑、终端、调试、Git 操作都走 WSL 工具链，而文件读写走 Windows NTFS，不会经过 /mnt/c 的 FUSE 层转换，规避了大部分兼容性问题。
code . 在 WSL 终端里执行会掉进坑
这是最常被踩的误区：在 WSL 的 bash 里执行 code /mnt/c/dev/myapp，看似打开了项目，实则 VSCode 会把它识别为「WSL 内部路径」，强制启用远程协议处理整个工作区——哪怕路径指向 /mnt/c。结果就是：
- 保存时提示
Unable to write file（尤其对符号链接或 NTFS 权限受限文件） - Git 显示所有文件为 modified（因行尾换行符或文件属性差异被误判）
- Python 插件找不到
venv（路径在/mnt/c/...下，但 Python 解释器路径解析错乱） - 终端启动的是 WSL shell，但当前工作目录却是 Windows 路径，pwd 输出为
/mnt/c/...，和 Windows 应用预期不一致
根本原因：VSCode 对 /mnt/c/ 下路径的自动检测逻辑不可靠，且无法保证所有插件适配这种混合模式。
需要真正 WSL 原生路径时，别碰 /mnt/c
如果你确实要编辑存放在 WSL 文件系统里的项目（例如 /home/user/mywslproj），那就老老实实把代码放在 WSL 根下。这时候：
- 直接在 WSL 终端里执行
code /home/user/mywslproj是安全的 - VSCode 自动识别为 WSL 远程工作区，所有路径、权限、文件事件都走原生 Linux 语义
- Windows 端也能通过
\wsl$Ubuntuhomeusermywslproj访问（仅限浏览/复制，不建议直接编辑）
跨系统共享开发环境的关键，是分清「编辑位置」和「运行位置」：编辑在 Windows 文件系统，运行和构建交给 WSL；或者编辑和运行都在 WSL 文件系统。混用 /mnt/c 作为编辑路径，等于同时挑战 NTFS 和 Linux VFS 的边界，没有稳定解法。
真正麻烦的从来不是怎么打开，而是打开之后 VSCode 底层怎么解释那个路径——它认你是 Windows 文件，还是 WSL 文件，决定了后面所有行为是否可信。
