PowerShell 更新后失效先看哪一页：排查顺序与核对清单
Windows 更新或 PowerShell 自身版本升级后，更新原本能跑的后失核对脚本突然报错、模块加载失败、效先计划任务不执行，看页这类问题在运维和办公自动化场景里并不少见。排查很多人第一反应是顺序重装或回滚系统，其实更稳妥的清单做法是先按顺序核对几个关键页面和入口，把「环境变了什么」确认清楚。更新本文给出一条从快到慢的后失核对排查路径，并说明每一步该看哪一页、效先看什么、看页看完怎么判断，排查帮助你在不动系统的顺序前提下定位大部分失效原因。
需要说明的清单是，不同 Windows 版本、更新不同 PowerShell 版本（Windows PowerShell 5.1 与跨平台的 PowerShell 7.x 并存很常见）的界面和路径存在差异，下文给出的入口以常见系统界面为准，具体以你本机实际界面和官方文档为准。涉及组策略、执行策略等安全设置时，只做指引，不替代组织内部的安全规范。
第一页：先看版本与安装信息，确认「跑的是哪一个 PowerShell」
更新后失效，最常见的原因是脚本被另一个版本的 PowerShell 接管了。Windows 自带的是 Windows PowerShell 5.1，路径通常在系统目录下的 WindowsPowerShell 文件夹；而 PowerShell 7.x 是独立安装，路径和程序名都不同。如果快捷方式、计划任务、IDE 终端指向的仍是旧路径，或反过来指向了新版本，表现就是「以前能跑现在不能跑」。
操作上，先在终端执行 $PSVersionTable，看 PSVersion 和 PSEdition 两项：Desktop 对应 5.1，Core 对应 7.x。再看 $PSHOME 确认程序目录。然后逐一核对调用方——桌面快捷方式属性里的目标、任务计划程序里「操作」页的命令行、编辑器终端配置里的 shell 路径。哪一页显示的路径和你以为的不一致，问题往往就在那里。
如果确认是版本切换导致，不要急着卸载新版本。先判断脚本是否依赖仅在 5.1 可用的模块（例如部分系统管理模块），这类情况更适合在调用处显式指定 powershell.exe 或 pwsh.exe，而不是改全局默认。
第二页：看执行策略与安全设置，确认脚本是否被拦截
更新有时会把执行策略重置为更严格的默认值，表现为脚本直接拒绝运行，提示「禁止运行脚本」。此时在终端执行 Get-ExecutionPolicy -List，会按作用域列出策略值，注意看 Process、CurrentUser、LocalMachine 各是什么，以及是否有组策略来源覆盖。组策略来源的优先级最高，改注册表也没用，这一页能直接告诉你「是谁在管」。
如果显示来源是组策略，应联系所在组织的 IT 管理员确认规范，不要自行绕过。如果是本机作用域过严，可在明确风险的前提下用 Set-ExecutionPolicy -Scope CurrentUser 调整，并记住这是安全边界：放宽执行策略等于允许本地脚本运行，来源不明的脚本不要执行。企业环境中还可能有应用控制策略、杀毒软件脚本扫描拦截，这类拦截通常有日志页可查，先看拦截记录再判断是不是 PowerShell 本身的问题。
第三页：看模块路径与加载报错，确认依赖是否还在
版本升级后模块搜索路径（PSModulePath）可能变化，自定义模块、内部模块找不到，报「无法识别命令」。先执行 $env:PSModulePath 看路径列表，再用 Get-Module -ListAvailable 看已安装模块及其版本，对照报错信息里的模块名，判断是路径缺失还是版本不兼容。
常见失败分支有三种：一是模块装在旧版本目录下，新版本不扫描该路径；二是模块清单要求的最低 PowerShell 版本高于当前版本；三是模块依赖的 .NET 运行时版本不匹配，多见于 PowerShell 7.x 小版本升级之后。处理顺序建议是：先把模块目录加入当前会话的 PSModulePath 验证可用，再决定是否写入用户环境变量长期生效；能升级模块就升级，不能升级再考虑在调用处固定使用旧版本 PowerShell。
另外别忽略日志。事件查看器里「Windows PowerShell」和「PowerShell」相关日志会记录模块加载失败、脚本执行错误；任务计划程序里失败的任务也有「上次运行结果」页可看返回码。这些页面比反复试错更快指向根因。
第四页：看调用方与权限，确认不是「环境外」的原因
还有一类失效与 PowerShell 本身无关：计划任务换了运行账户、脚本所在网络路径权限变化、系统更新后重启导致服务未启动。核对清单可以这样走：任务计划程序看「常规」页的账户与「是否使用最高权限运行」，看「操作」页的起始目录是否正确；脚本文件属性看是否被标记为来自网络而受阻止；服务管理器看依赖服务状态；最后用同一账户手动执行一次脚本，对比手动成功、计划失败的情况，基本能锁定是权限或上下文问题。
如果以上几页都核对过仍无法定位，建议保留完整报错文本、$PSVersionTable 输出、执行策略列表和事件日志时间点，再向厂商支持或组织 IT 提交，比笼统描述「更新后不能用了」效率高得多。
小结：PowerShell 更新后失效，先看版本与安装信息页确认跑的是哪个版本，再看执行策略页确认是否被拦截，然后看模块路径与加载报错页确认依赖完整，最后核对调用方与权限页排除环境外因素。四步走完，多数问题能在不改动系统的前提下定位；涉及组策略和安全策略的调整，以当地官方说明和组织规范为准。