VSCode报“Access Denied”主因是终端权限、PowerShell执行策略或WSL路径问题；应优先检查PowerShell策略（设RemoteSigned）、项目移至非系统路径、使用Remote-WSL扩展而非\wsl$路径。
VSCode运行代码报 Access Denied，基本不是VSCode自身缺陷，而是它调用的终端（PowerShell/CMD/WSL）在执行命令时被Windows权限机制拦截——关键得看命令想写哪、当前用户有没有那把“钥匙”。
PowerShell执行策略阻止脚本运行
这是Windows上最常被误认为“拒绝访问”的真实原因。错误信息通常是：File XXX.ps1 cannot be loaded because running scripts is disabled on this system. 它不提“Access Denied”，但行为完全一致：脚本静默失败，终端卡住或退出。
- 运行
Get-ExecutionPolicy -List查看当前策略，重点关注CurrentUser行；若为Restricted，本地脚本一律禁止执行 - 仅对当前用户放行：
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser（无需管理员权限，安全且可逆） - 别用
Unrestricted或Bypass，尤其在公司电脑上，组策略可能随时覆盖，还可能触发安全审计告警 - 如果项目里有自定义
.ps1构建脚本，这条必须先解决；否则改再多文件夹权限也没用
终端继承权限不足，不是VSCode没开管理员模式
VSCode内置终端（PowerShell/CMD/Git Bash）默认以你当前登录用户的**标准令牌**启动，哪怕你是管理员账户，它也拿不到写入 C:Program Files 或监听 :80 端口的权限。
Accessibility Review
下载
对设计或页面进行 WCAG 2.1 AA 无障碍审计。触发关键词：“audit accessibility”、 “check a11y”、 “is this accessible?” 或在审查设计时使用。
- 不要长期勾选VSCode快捷方式的“以管理员身份运行此程序”——这会让所有终端子进程都带高权限，npm postinstall 脚本可能以 admin 身份执行恶意代码
- 真正该做的是：把项目移到非系统路径，比如
D:projectsmyapp或C:devmyapp，避开C:UsersXXXOneDrive、Downloads这类受Windows实时保护锁定的同步目录 - 检查终端启动时的实际路径：
pwd或cd回车，确认不在C:Windows、C:Program Files或 OneDrive 根目录下 - 如果必须全局安装 CLI 工具（如
npm install -g typescript），优先配npm config set prefix ~/.local+ 把~/.local/bin加进 PATH，而不是硬刚管理员模式
WSL环境下通过\wsl$路径编辑文件必然权限异常
这是Windows+WSL双系统开发者最容易踩的坑。你在资源管理器里打开 \wsl$Ubuntuhomeuserproject，再用VSCode打开这个路径——表面能读写，实际所有保存操作都经由Windows ACL转发，Linux的 chmod 和 chown 失效，Git 提交、文件重命名经常报 Access Denied。
- 唯一可靠方案：装官方
Remote - WSL扩展，按Ctrl+Shift+P→ 输入Remote-WSL: New Window，在新窗口中用code /home/user/project直接打开Linux原生路径 - 绝对避免对
/mnt/c/下的项目直接chown -R $USER——Windows文件没有真正的UID/GID，强行改会破坏挂载元数据，后续可能连ls都变慢 - 如果已出现
Permission denied且属主是root，先确认是否在/mnt/c下：运行ls -ld .，若显示drwxr-xr-x 1 root root，说明路径挂载逻辑错位，应迁移到/home/user再重新克隆仓库
真正麻烦的从来不是单点权限设置，而是 PowerShell 策略 + \wsl$ 路径 + 杀软实时防护三者叠加——每次只动一项，否则你永远不知道是哪把锁卡住了门。
