VSCode报“权限不足”90%是文件、目录或挂载点权限问题，非编辑器故障；用ls -l查文件属主与w位、ls -ld查父目录写权限、mount | grep查挂载选项即可快速定性。
VSCode在Linux下报“权限不足无法写入”，90%不是VSCode的问题，而是当前用户对目标文件或其父目录没有写权限——直接改权限或切路径就能解决，不用动系统配置或开管理员模式。
怎么快速定位是文件、目录还是挂载点的问题
别猜，三行命令定性：
-
ls -l /path/to/file：看第三列所有者是不是你，第一列权限里有没有w（比如-rw-r--r--表示你有写权，-r--r--r--就没有） -
ls -ld /path/to/parent：关键！即使文件可写，若父目录权限是dr-xr-xr-x且你不是属主，VSCode 保存时会失败——Linux 要求对目录有w才能覆盖或重命名文件 -
mount | grep $(dirname /path/to/file)：如果路径在/mnt/c、/media或网络盘里，输出中没metadata或含ro、noexec，就是挂载配置问题
修复文件/目录所有权最安全的做法
避免sudo chown -R $USER: .这种粗暴操作，容易误伤node_modules或构建产物。按需最小范围修正：
- 只修单个文件：
sudo chown $USER:$USER /path/to/broken.file - 修整个子目录（如
src/），且确认里面没第三方依赖：sudo chown -R $USER:$USER ./src - 修目录本身（常被忽略）：
sudo chmod u+w /path/to/project-root，确保你对项目根目录有w权限 - 别碰
/proc、/sys、/dev这类虚拟文件系统——chown会失败或静默无效
为什么chmod 777或sudo code反而让问题更糟
这两招看似快，但埋下长期隐患：
-
chmod 777让所有用户可写，破坏最小权限原则；若项目含敏感配置（如.env），等于裸奔 -
sudo code启动后，所有终端、调试器、插件都继承root权限：生成的二进制文件属主变成root，下次普通用户执行make clean就失败；git可能因~/.ssh权限不匹配而认证失败 - 插件安装也会卡住：
code --install-extension在管理员上下文里基本不可用，得手动下载.vsix再导入
WSL用户特别注意/mnt/c路径的元数据开关
Windows 文件挂进 WSL 后默认不认chmod和chown，必须启用元数据支持：
- 编辑
/etc/wsl.conf，确保包含：[automount] enabled = true options = "metadata,uid=1000,gid=1000,umask=022"
- 改完必须执行
wsl --shutdown，再重新打开 WSL——不重启，配置不生效 - 验证：
touch /mnt/c/test && ls -l /mnt/c/test，能看到属主是你、权限含w才算成功 - 更推荐方案：把项目移到
~/projects/等原生 Linux 路径，彻底避开跨文件系统权限映射问题
真正容易被忽略的是父目录的w权限和 WSL 的metadata开关——前者查ls -ld一眼就能发现，后者不重启 WSL 就永远不生效。
