VSCode中tsc报错是因CurrentUser作用域PowerShell执行策略为Restricted，只需运行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser并重启终端即可解决，无需管理员权限且安全有效。
直接改 CurrentUser 作用域的执行策略为 RemoteSigned，然后重启 VSCode 终端——这是最安全、最有效、且无需管理员权限的解法。
为什么 VSCode 里 tsc 报这个错，而 CMD 或 PowerShell 窗口却没事？
VSCode 默认启动的是当前用户的 PowerShell 进程（不是系统级，也不是管理员级），它只读取 CurrentUser 作用域的执行策略。你用管理员打开的独立 PowerShell 窗口可能改了 LocalMachine，但 VSCode 根本不看那儿；CMD 没这限制，因为它压根不走 PowerShell 执行策略这套机制。
验证方式：在 VSCode 内置终端运行：
Get-ExecutionPolicy -List
重点关注 CurrentUser 那一行——如果显示 Undefined 或 Restricted，就是它拦着 tsc.ps1 了。
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser 是唯一推荐的操作
这条命令只影响当前 Windows 用户，不需要管理员权限，也不会动系统其他设置，刚好放开本地脚本（比如 tsc.ps1、ng.ps1、npm.ps1）的执行，同时仍拦截从网络下载且未签名的脚本，安全边界清晰。
- 别用
Unrestricted：会绕过所有签名检查，还弹提示，纯添堵 - 别用
AllSigned：你本地写的.ps1也得手动签名，开发根本没法推进 - 别漏掉
-Scope CurrentUser：没这个参数，默认改的是LocalMachine，需要管理员权限，且 VSCode 不认 - 执行后必须关掉再重开 VSCode 终端：PowerShell 进程不重启，新策略不加载
遇到“Access is denied”或“拒绝访问”怎么办？
说明你当前 PowerShell 进程权限不够，但**不需要也不应该以管理员身份运行 VSCode**——那反而可能写到错误的作用域。正确做法是：
- 在任意终端（哪怕普通 CMD）里，直接运行：
powershell -Command "Set-ExecutionPolicy RemoteSigned -Scope CurrentUser -Force" - 或者用 Windows 开始菜单打开「Windows PowerShell」（非管理员），再跑上面那条
Set-ExecutionPolicy命令 - 如果公司设备被组策略锁死（
MachinePolicy显示Defined），那本地改无效，得找 IT 部门申请白名单，而不是硬刚策略
真正卡住人的从来不是命令本身，而是没确认 CurrentUser 策略是否生效、没重启终端、或者误以为改了系统级策略就一劳永逸——策略是按作用域加载的，不是全局广播的。改完记得跑一次 Get-ExecutionPolicy -Scope CurrentUser 看输出是不是 RemoteSigned，眼见为实。
