根本原因是VSCode继承启动时的权限上下文，若用sudo code启动或项目目录属root，则普通用户无法写入；需检查ls -ld和ls -l确认归属，再用sudo chown -R $USER:$GROUPS修复，禁用sudo code并避免chmod 777。
为什么 VSCode 保存文件时突然报 EACCES: permission denied
根本原因不是 VSCode 本身没权限，而是它试图写入的路径（比如 /usr/local/bin、/opt/xxx 或你用 sudo code 打开过项目）被系统限制了普通用户写入。常见于：手动用 sudo code . 启动过编辑器、项目在 root 创建的目录里、或通过包管理器（如 Homebrew）安装了需提权的 CLI 工具后残留了高权限文件夹。
检查并修复当前文件/目录所有权
先确认问题范围——是单个文件、整个文件夹，还是全局配置？别急着改权限，先看归属：
- 终端进到出问题的目录，运行
ls -ld .看当前文件夹归属；再ls -l filename看具体文件 - 如果显示类似
root:staff或root:root，说明这目录/文件是 root 创建的，普通用户无法覆盖 - 修复命令：
sudo chown -R $USER:$GROUPS ./your-project-folder（macOS/Linux）；Windows WSL 同理，但注意别对/etc或/usr盲目递归 - 切忌直接
chmod 777—— 这会绕过系统安全策略，某些 macOS 版本甚至会触发 SIP 保护导致更奇怪的失败
VSCode 启动方式决定权限边界
VSCode 本身不以 root 运行，但它继承了启动它的 shell 的权限上下文。错误启动方式会污染整个工作区：
- 永远不要用
sudo code .打开项目——这会让 VSCode 以 root 身份读取文件，后续保存时尝试以 root 权限写回，而你当前用户没这个能力 - 如果已这么干过，清理残留：
rm -rf ~/.config/Code/Cache和rm -rf ~/.config/Code/CachedData（Linux/macOS），否则缓存可能持续携带错误 uid - macOS 上从 Dock 或 Launchpad 启动的 VSCode 默认走用户上下文；但从终端用
sudo启动，就会卡死在权限套娃里 - 检查是否启用了「Remote-SSH」或「Dev Containers」：这些场景下权限由远端系统决定，本地修复无效，得去目标机器上查
whoami和id -u
避免未来再踩坑的硬约束
真正的麻烦不在修复，而在下次又掉进去。几个必须守住的线：
- 所有项目目录必须由当前用户创建：
mkdir ~/projects/myapp && cd $_，而不是sudo mkdir /var/www/myapp - 全局 CLI 工具（如
pnpm、deno）尽量用用户级安装（curl | sh到$HOME/.local/bin），别往/usr/local/bin塞 - VSCode 设置里关掉
files.autoSave临时规避？不行——这只是掩盖问题，等你 Ctrl+S 时照样崩 - 如果开发必须操作系统级路径（比如写 systemd service 文件），用终端
sudoedit /etc/systemd/system/xxx.service，别硬塞进 VSCode
权限问题从来不是“改个数字就完事”，它背后是进程身份、文件系统挂载选项、甚至容器命名空间的叠加效应。修一次要顺手查三处归属，不然下周又在同一个 EACCES 里打转。
