PowerShell脚本跑不起来最常见的原因是执行策略限制，可通过Get-ExecutionPolicy查看当前策略，并用Set-ExecutionPolicy RemoteSigned命令修改以允许本地脚本运行，若仍无法执行则需检查脚本路径是否正确、是否存在语法错误、文件编码是否为UTF-8不带BOM、是否以管理员权限运行以及杀毒软件是否拦截，同时可借助Write-Host输出调试信息、使用Set-StrictMode启用严格模式、结合Try-Catch捕获错误并利用VS Code等工具进行断点调试，最终根据错误提示精准定位问题并解决，整个排查过程应从执行策略入手逐步扩展到环境与代码本身，确保每个环节都符合运行要求。
PowerShell脚本跑不起来，这事儿真挺让人抓狂的，尤其当你觉得代码明明没问题的时候。多数情况下，这背后最常见的原因就是执行策略（Execution Policy）在作祟，它就像一道安全门，阻止了未经允许的脚本运行。当然，也可能是脚本本身有语法错误、路径不对，或者权限不够。
要解决PowerShell脚本无法执行的问题，核心思路就是先搞清楚它为什么被拦住了。通常，我们会从调整执行策略入手，这是最直接也最常见的解决方案。你可以临时放宽限制，让脚本跑起来，然后再考虑更安全的长期方案，比如对脚本进行签名。
如何检查和修改PowerShell的执行策略？
这几乎是排查PowerShell脚本执行问题的首要步骤，也是我个人在遇到这类情况时，下意识会去做的第一件事。PowerShell为了安全考量，默认的执行策略往往比较严格，比如在客户端系统上可能是
Restricted，这意味着任何脚本都不能运行。
要查看当前的执行策略，你只需要打开PowerShell，然后输入：
Get-ExecutionPolicy
这会告诉你当前是哪种策略，比如
Restricted、
AllSigned、
RemoteSigned、
Unrestricted或
Bypass。
当你需要运行脚本时，尤其是自己写的或者从可靠来源获取的脚本，最常用的方法就是将其设置为
RemoteSigned。这个策略允许本地创建的脚本运行，但从网上下载的脚本则需要数字签名。对于个人开发或内部使用，这通常是个不错的平衡点。
修改执行策略的命令是：
Set-ExecutionPolicy RemoteSigned
执行时，系统会提示你确认，输入
Y并回车即可。
如果你只是想临时运行一个脚本，不想永久修改策略，可以在执行完脚本后，再把策略改回原来的设置。但说实话，很多人为了方便，可能就一直保持
RemoteSigned了，这在个人开发机上倒也无妨，但在生产环境或共享机器上，就得更谨慎些。
有时候，你可能会遇到“无法更改执行策略”的提示，这通常是组策略（Group Policy）在捣乱。这种情况下，你需要联系你的系统管理员，或者自己去检查本地组策略编辑器（
gpedit.msc），看看是不是有策略禁用了执行策略的修改。这比单纯的
Set-ExecutionPolicy要复杂一些，涉及到更深层次的系统管理权限。
除了执行策略，还有哪些常见原因导致脚本无法运行？
执行策略固然是头号嫌疑犯，但如果改了策略还是不行，那问题可能就出在其他地方了。我见过不少情况，明明执行策略设置对了，脚本却依然纹丝不动，或者报错。
一个很常见的坑是脚本路径或文件名不对。听起来很傻，但真的经常发生。比如你把脚本放在了桌面，结果在PowerShell里直接输入文件名就想运行，那肯定不行。你需要提供完整的路径，或者先
cd到脚本所在的目录。
# 完整路径执行 C:\Users\YourUser\Desktop\MyScript.ps1 # 切换目录后执行 cd C:\Users\YourUser\Desktop .\MyScript.ps1
注意那个
.\，在PowerShell里，它表示当前目录，执行当前目录下的脚本时是必须的，否则PowerShell会把它当成一个命令来查找。
再来就是脚本本身的语法错误。这没啥好说的，代码写错了，肯定跑不起来。PowerShell的错误提示通常还算友好，仔细看看报错信息，它会告诉你哪一行出了问题，或者哪个命令不识别。我个人习惯是，如果脚本复杂，我会分段测试，或者用VS Code之类的IDE来写，它能提供实时的语法检查。
文件编码问题也偶尔会跳出来捣乱。特别是当你从网上复制粘贴代码，或者在不同操作系统之间传输文件时，编码格式不对（比如UTF-8带BOM和不带BOM，或者ANSI）就可能导致脚本解析失败。用记事本或者VS Code把文件另存为UTF-8（不带BOM）通常能解决这个问题。
还有就是权限不足。即使执行策略允许，如果你尝试操作一些需要管理员权限的系统资源（比如修改注册表、安装服务），但PowerShell会话不是以管理员身份运行的，那它一样会报错。解决办法很简单，右键点击PowerShell图标，选择“以管理员身份运行”。
最后，别忘了杀毒软件。有些杀毒软件可能会误判PowerShell脚本为恶意行为，直接拦截其运行。这种情况比较少见，但如果以上方法都试过了，不妨暂时禁用一下杀毒软件，或者把脚本所在的目录添加到白名单里。这有点像“玄学”，但确实是偶尔会遇到的情况。
遇到脚本错误时，如何进行有效的调试？
脚本无法执行，很多时候并不是“不能运行”，而是“运行了但报错了”。这时候，调试就成了你的救命稻草。有效的调试能让你迅速定位问题所在，而不是像无头苍蝇一样乱撞。
最直接粗暴，但意外好用的方法，就是Write-Host
大法。在脚本的关键位置，用
Write-Host输出变量的值、执行到哪一步了，就像在代码里埋下了一个个探头。
$myVariable = "Hello" Write-Host "变量myVariable的值是: $myVariable" # 接下来是可能出错的代码
虽然这看起来有点原始，但在快速定位问题时非常有效，特别是对于那些不熟悉复杂调试器的开发者来说。
更高级一点，PowerShell提供了Set-StrictMode
。把它放在脚本开头，可以强制PowerShell对未声明的变量、函数等进行更严格的检查，这能帮你发现一些潜在的逻辑错误或打字错误，避免它们在后期造成更大的麻烦。
Set-StrictMode -Version Latest # 你的脚本代码
当脚本可能因为某些操作失败而中断时，Try-Catch
块是你的好朋友。它能优雅地捕获错误，让你在错误发生时执行特定的操作，比如记录日志、给出友好的提示，而不是直接让脚本崩溃。
Try {
# 尝试执行可能出错的代码
Get-Item "C:\NonExistentFolder" -ErrorAction Stop # 强制报错
}
Catch {
Write-Error "发生错误: $($_.Exception.Message)"
# 可以在这里记录日志或执行其他恢复操作
}注意这里的
-ErrorAction Stop，它很重要，因为它能确保
Try块内的命令在出错时真的抛出终止错误，从而被
Catch块捕获。很多PowerShell命令默认只抛出非终止错误，不会被
Catch捕获。
对于更复杂的调试，PowerShell ISE（如果你还在用的话）或VS Code都提供了强大的集成调试器。你可以设置断点，单步执行代码，检查变量状态。这就像给你的脚本做X光，能看到它内部的每一个细节。
最后，别忽视PowerShell的错误信息本身。它们往往包含了大量有用的线索，比如错误类型、出错的行号、甚至是建议的解决方案。很多时候，把错误信息复制到搜索引擎里一搜，就能找到答案。我个人经验是，越是看起来晦涩难懂的错误，越可能是一个普遍存在的问题，网上能找到很多讨论。
