企业官网建设流程全解析

如果你手上有一台 Windows，想给 PowerShell 更新一下，最省事的做法真的就是一行命令：winget install --id Microsoft.PowerShell --source winget。敲下去，等进度条走完，关掉窗口重开，$PSVersionTable里的版本号就变了。整个过程不需要点下一步、不需要选安装路径、不需要在官网上一层层找下载链接。

但这里面有个前提：你得先搞清楚自己想更新的是哪一个 PowerShell。Windows 上同时存在两套 PowerShell——系统自带的 Windows PowerShell 5.1（powershell.exe）和独立发布的 PowerShell 7（pwsh.exe）。前者是操作系统组件，压根不能用包管理器升级；后者才是那条一行命令真正能搞定的目标。我见过太多人把这两件事搞混，然后拿着一行winget命令去"升级 5.1"，结果命令执行成功、版本号纹丝不动，最后得出"这条命令是骗人的"这个结论。

这篇内容就是把这行命令讲透：它到底做了什么、什么场景下能用、参数为什么这么写、更新完之后哪些地方会跟着变、装不上时怎么一步步定位。看完你应该能在自己机器上、在同事的机器上、在几十台的内网机器上，把这件事一次做对。

1. 先分清你要更新的是哪一个 PowerShell，这决定了那行命令长什么样

动手之前花两分钟做一次身份确认，比装完发现问题再回头查要划算得多。

1.1 同一台机器上的两套 PowerShell：powershell.exe 与 pwsh.exe

打开任意一个终端，敲：

$PSVersionTable | Format-List

重点看两个字段：PSVersion和PSEdition。如果PSVersion是 5.1.x 且PSEdition是Desktop，那你现在跑的是 Windows PowerShell；如果PSVersion是 7.x 且PSEdition是Core，那就是 PowerShell 7。这两个东西的 exe 名字不一样，powershell.exe对应 5.1，pwsh.exe对应 7，它们可以同时存在于一台机器上，互不覆盖，路径也完全不同。

这张表是后面所有操作的基础。你在任务计划里写的是powershell.exe还是pwsh.exe，直接决定了升级动作对它有没有影响。

这里有个很多人第一次接触时会绕进去的点：PowerShell 7 不是 5.1 的"升级版"。它俩是并行的两条产品线，7 引入了 .NET Core 运行时、跨平台支持、新的运算符和默认 UTF-8 编码，但为了兼容老脚本，5.1 依然会被系统保留下来。微软自己的说法是 5.1 只做安全修复，不再有新功能。所以"给 PowerShell 更新"这件事，在 2024 年之后基本等价于"装一个最新版的 PowerShell 7"。

1.2 一行命令能覆盖的范围，以及它覆盖不了的部分

winget这一行命令能做的，是从 winget 的软件源里查询Microsoft.PowerShell这个包标识，下载最新的稳定版 MSI（或 MSIX），静默安装，并把pwsh.exe加到系统 PATH 里。它管的是 PowerShell 7，管不了 5.1。

那 5.1 怎么办？答案是：你基本不用管。在 Windows 10 和 Windows 11 上，5.1 的版本号跟随操作系统版本走，比如5.1.22621.x对应 Win11 22H2 这一代。系统补丁日推什么，它就是什么。想手动确认当前版本，可以跑：

Get-Item $PSHOME\powershell.exe | Select-Object -ExpandProperty VersionInfo | Select-Object FileVersion, ProductVersion

在 Windows 7 SP1 这种老系统上情况特殊一些，需要单独安装 WMF 5.1（Windows Management Framework），而它有一串前置条件：系统要 SP1 打全、.NET Framework 要 4.5.2 以上、还需要通用 C 运行库的补丁。这也是"安装程序无法安装 Windows PowerShell"这类报错最集中的来源，后面第 5 节会专门讲。

至于winget本身，Win10 1809 之后的系统一般自带 App Installer，如果敲winget提示找不到命令，说明 App Installer 没装或者被裁剪过（LTSC 版本常见），这时候要么走商店补装 App Installer，要么直接跳到第 4 节用 MSI 安装包。

提示：判断你该走哪条路，就看$PSVersionTable.PSEdition。Desktop 走系统更新思路，Core 走包管理器思路，两条路的动作完全不重叠。

2. 把那行命令拆开：每个参数都在解决一个具体的麻烦

很多人抄命令只抄winget install Microsoft.PowerShell就完事了，在交互式的桌面环境里确实能用，但一旦放到脚本里、放到无人值守的场景里，就会卡在某个询问上不动。

2.1 最短可用的写法与推荐写法

给个人机器用，这一行足够：

winget install --id Microsoft.PowerShell --source winget

但我更推荐下面这个长一点的版本，它把几个交互点提前关掉了：

winget install --id Microsoft.PowerShell --source winget ` --accept-package-agreements --accept-source-agreements ` --silent --disable-interactivity

如果你已经装过了，只是想升级到最新版，那么用upgrade更精准，它不会在已经是最新版本时重复下载一遍安装包：

winget upgrade --id Microsoft.PowerShell --source winget ` --accept-package-agreements --accept-source-agreements --silent

顺手提一句，winget list --id Microsoft.PowerShell和winget upgrade是两个高频命令：前者确认当前装的版本和可用版本，后者列出所有可升级的包。我习惯先在winget upgrade的输出里扫一眼有没有 PowerShell，再决定要不要单独升级，免得顺手把别的包一起升了带来意外。

2.2 参数逐条解释：每个 flag 对应的都是踩过的坑

--id这个参数最值得说的是"为什么不用--name"。--name是模糊匹配，而--id是精确匹配。当你写winget install PowerShell的时候，搜索逻辑会去匹配名称、描述、发布者等字段，有可能返回多个候选让你选。在交互环境下这没问题，但脚本里一旦出现候选项就会退出，然后你看到的就是一句莫名其妙的失败。所以脚本里永远用--id。

--source winget也值得单独说。winget 常见的源至少有两个：默认的社区源（标识就是winget）和msstore。两者装的都是 PowerShell 7，但产物形态不一样：社区源装的是 MSI，走传统安装路径，用Program Files\PowerShell\7作为主目录；msstore装的是商店打包版（MSIX），由商店负责更新，但对企业批量分发不太友好。个人用户哪个都行，但你要清楚自己选的是哪个，因为它决定了你以后的升级动作是敲命令还是等商店后台自己转。

2.3 不同安装来源的命令对照

环境不同，那一行命令的形态也不同。我把常见几种整理在下面，你可以直接按自己的场景取用。

# 社区源，最通用 winget install --id Microsoft.PowerShell --source winget --silent # 商店源，适合愿意交给商店自动更新的个人用户 winget install --id Microsoft.PowerShell --source msstore # Scoop scoop install pwsh # 首次 scoop update pwsh # 后续更新 # Chocolatey choco upgrade powershell-core -y

如果这些包管理器都没有，也不想装，那就回到最原始的方式——下载 MSI 手动静默安装：

msiexec /i "PowerShell-7.4.6-win-x64.msi" /quiet /norestart ` ADD_PATH=1 REGISTER_MANIFEST=1 ENABLE_PSREMOTING=1 USE_MU=1 ENABLE_MU=1

这一串 MSI 属性名字很丑，但它其实是把安装向导里的复选框搬到了命令行上：ADD_PATH=1把pwsh.exe目录写进 PATH，REGISTER_MANIFEST=1注册文件清单，ENABLE_PSREMOTING=1打开远程管理所需的监听，USE_MU=1和ENABLE_MU=1让这个软件接受系统更新通道的管理。这四个开关默认是关的，这就是为什么很多人手动点安装向导装完之后，发现和winget装出来的行为不太一样。

注意：ENABLE_PSREMOTING=1会动 WinRM 相关配置。如果你的机器有安全基线要求，装之前最好和负责这块的人对一下，不要自己顺手打开。

3. 更新完成后第一件该做的事：把编码和执行策略对齐

装完了、版本号也变了，事情只做了一半。从 5.1 跨到 7，有两处默认行为的差异会让老脚本直接趴窝，而且报错信息往往不指向真正的原因。

3.1 乱码的根因在代码页，不在字体

从 5.1 切到 7 之后，最常见的现象是：脚本里输出的中文变成了一串问号或者方块。很多人第一反应是字体问题或者终端问题，改了半天终端的字体设置，没有任何效果。真正的原因在编码管线上。

5.1 在中文 Windows 上默认使用系统区域对应的代码页（GBK，也就是 936），而 PowerShell 7 默认走 UTF-8。当输出经过一层管道、或者被重定向到文件、或者被另一个程序（比如某个 Python 工具）读取时，两端的编码假设对不上，就出乱码。可以这样快速确认和对齐：

# 查看当前终端代码页 chcp # 临时切到 UTF-8 chcp 65001 # 让 PowerShell 的输出编码按 UTF-8 走 [Console]::OutputEncoding = [System.Text.UTF8Encoding]::new($false) $OutputEncoding = [System.Text.UTF8Encoding]::new($false) # 让所有带 -Encoding 参数的 cmdlet 默认用 utf8 $PSDefaultParameterValues['*:Encoding'] = 'utf8'

前三行是临时生效，关掉窗口就恢复。想持久化，可以把后两行写进$PROFILE。另外还有一个容易被忽略的地方：外部命令输出到 PowerShell 时的解码是靠[Console]::OutputEncoding控制的，而 PowerShell 往外部命令写输入时靠的是$OutputEncoding。这两个是分开的，只改一个经常出现"读进来正常、写出去乱码"或者反过来的情况。

如果你是通过注册表把系统区域设置里的"使用 Unicode UTF-8 提供全球语言支持"勾上了，那 5.1 那边的行为也会跟着变，这时候反而可能出现原本正常的 5.1 脚本开始乱码——因为有些老脚本是明确按 GBK 写的。这种改动建议一次只动一处，动完立刻验证，别两件事一起改。

3.2 自启脚本与计划任务在升级后的失效形态

PowerShell 相关的开机自启，常见的有三种实现：启动文件夹里的快捷方式、注册表Run键、任务计划程序里的任务。升级之后它们的失效方式各不相同。

最隐蔽的是任务计划里写死了绝对路径的那种。比如你的任务里配的是C:\Program Files\PowerShell\7\pwsh.exe，从 MSI 版切到商店版之后，这个路径就不存在了，任务会静默失败——事件日志里可能只有一行很不起眼的记录。判断方法很简单，直接跑一次手动触发，看返回码。

第二类是执行策略变化导致的。升级不会主动改你的执行策略，但如果你之前给 5.1 单独设过策略，7 是独立的一套配置，不会继承。所以升级完先看一眼：

Get-ExecutionPolicy -List # 只给当前用户放开本地脚本，改动范围最小 Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

我个人的习惯是永远只改CurrentUser作用域，不动LocalMachine。原因很直接：LocalMachine是机器级的，会影响这台机器上所有用户和所有自动化任务，改错了排查起来非常麻烦；而CurrentUser出问题最多影响你自己，删掉重设就行。改完之后用Get-ExecutionPolicy -List复查一遍，确认生效的作用域是你想要的那个。

第三类是自启脚本里依赖的模块在 7 下加载失败。这类问题的表现是脚本跑了但功能没生效，而不是直接报错，最难查。排查思路后面第 6 节里会讲。

3.3 $PROFILE 的迁移与踩坑点

$PROFILE是每个 PowerShell 版本、每个宿主各自独立的一份配置。5.1 的 profile 和 7 的 profile 不是一个文件，路径也不一样。升级之后你原来在 5.1 里写的别名、函数、默认参数，在 7 里全都不存在。

# 看当前用的是哪个 profile $PROFILE # 看这个文件是否存在 Test-Path $PROFILE # 把 5.1 的 profile 内容拷到 7 的 profile 里 $old = "$HOME\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1" $new = "$HOME\Documents\PowerShell\Microsoft.PowerShell_profile.ps1" if (Test-Path $old) { Copy-Item $old $new -Force }

但别直接拷完就完事。5.1 的 profile 里经常有一些只在 Desktop 版生效的写法，比如加载某些基于 .NET Framework 的模块、或者调用Add-Type编译一段老代码。这些内容拷到 7 里可能导致每次开终端都报错。我的做法是先拷过去，然后在新窗口里打开 7，看有没有报错，报错就一条条注释掉再定位。宁可 profile 少一点，也不要让它每次启动都吐一堆红字，红字看多了人会麻木，真正的问题就混在里面被忽略掉了。

提示：$PROFILE有多个层级（AllUsersAllHosts、AllUsersCurrentHost、CurrentUserAllHosts、CurrentUserCurrentHost），$PROFILE变量默认指向最具体的那一个。如果你要判断"这条配置到底从哪来的"，用$PROFILE | Format-List *把所有层级列出来挨个看。

4. 让这件事可重复：从手动敲一行到批量下发

一个人在终端里敲一行，和几十台机器上无人值守地跑，是两个完全不同的问题。手动场景下失败了你能看到报错重来；批量场景下失败了，你可能一两周后才发现。

4.1 把一行命令包进带退出码判断的脚本

winget的退出码在某些版本上并不完全可靠，尤其是走商店源的时候，可能出现"命令成功返回但实际没装成"的情况。所以脚本里不能只看退出码，必须做一次结果验证。

# update-pwsh.ps1 $ErrorActionPreference = 'Stop' $before = if (Get-Command pwsh.exe -ErrorAction SilentlyContinue) { (& pwsh.exe -NoProfile -Command '$PSVersionTable.PSVersion.ToString()') } else { 'none' } Write-Host "升级前版本: $before" winget upgrade --id Microsoft.PowerShell --source winget ` --accept-package-agreements --accept-source-agreements ` --silent --disable-interactivity # 用 winget list 的真实输出做验证，而不是信任退出码 $installed = (winget list --id Microsoft.PowerShell --source winget) -join "`n" if ($installed -notmatch 'Microsoft\.PowerShell') { throw "winget 执行完成，但未在已安装列表中确认到 Microsoft.PowerShell" } $after = & pwsh.exe -NoProfile -Command '$PSVersionTable.PSVersion.ToString()' Write-Host "升级后版本: $after"

这段脚本里最关键的其实是最后那两行验证。winget list的输出格式在不同版本间有变化，用正则去匹配包名是个折中方案——不够优雅，但足够稳当，而且当匹配失败时脚本会明确抛出异常，而不是安静地"成功"了。

另一个实用技巧是把版本号打印出来做前后对比。在批量场景下，你需要的不是"脚本没报错"，而是"版本确实从 7.2.9 变成了 7.4.6"。日志里留着这一行，三个月后回头查问题时能省很多事。

4.2 内网与离线场景：MSI、MSIX 与版本锁定

内网机器通常没有直连外部软件源的通道，这时候包管理器就用不上了，得走离线包。PowerShell 官方提供三种包：MSI（PowerShell-7.x.x-win-x64.msi）、MSIX 包（PowerShell-7.x.x.msixbundle）和 ZIP 压缩包。

MSI 适合批量部署，可以配组策略或者用部署工具推送，参数就是前面那段。MSIX 适合和商店体系对接，安装命令是Add-AppxPackage。ZIP 包最轻量，解压到任意目录就能用，但它不会注册 PATH、不会注册文件关联，适合放在移动介质或者受限环境里临时用。

# 离线安装 MSIX 包 Add-AppxPackage -Path ".\PowerShell-7.4.6.msixbundle" # 用 ZIP 包做便携使用 Expand-Archive .\PowerShell-7.4.6-win-x64.zip -DestinationPath C:\Tools\pwsh & C:\Tools\pwsh\pwsh.exe -NoProfile -Command $PSVersionTable.PSVersion

企业环境里我强烈建议锁定版本，也就是用--version 7.4.6这种明确的参数，或者内网只分发固定版本的 MSI。理由是 PowerShell 7 的版本节奏比较快，跟着最新版走意味着你每个季度都要重新做一轮兼容性验证。锁在一个长期支持版本上，验证一次能管很久。

4.3 用系统更新通道带着 pwsh 走

如果你不想自己维护升级节奏，还有一个"懒人方案"：让 PowerShell 7 跟着操作系统更新通道一起走。这就是前面 MSI 参数里USE_MU=1和ENABLE_MU=1的作用——它把 PowerShell 7 注册为接受更新通道管理的产品，之后系统更新扫描的时候会顺便看看它有没有新版本。

这个方案的好处是不需要任何人记得去升级，也不会出现"这台机器是 7.2、那台是 7.4"的版本漂移。代价是你失去了版本控制权，某个补丁日它可能一次跨好几个小版本。适合那种"不追求新特性、只要求能用且一致"的环境。

# 确认当前的更新通道相关注册项是否存在 Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*' | Where-Object { $_.DisplayName -like 'PowerShell*' } | Select-Object DisplayName, DisplayVersion, InstallLocation

这段命令用来确认"这台机器上的 PowerShell 7 是以什么形态装的、装的哪个版本"，排查版本漂移的时候很有用。

5. 装不上、装完不对：一条从表象到根因的排查链

升级失败是最容易让人急躁的环节，因为报错信息通常很短，指向性也不强。我的经验是别急着搜错误码，先按顺序把三件事问清楚。

5.1 三问定位：哪个版本、哪个来源、哪种安装方式

第一个问题：你操作的是 5.1 还是 7？如果是 5.1，winget一定无效，这属于用错工具，不是安装失败。

第二个问题：包来源是什么？社区源、商店源、还是手动下载的安装包。来源不同，失败原因完全不一样。社区源的失败多半是网络访问问题或者源索引过期（可以先跑winget source update）；商店源的失败多半是账户或者商店组件状态问题；手动安装包的失败则集中在包完整性、系统前置条件、以及权限三件事上。

第三个问题：是全新安装还是覆盖升级？覆盖升级会遇到"已有更高版本""文件被占用"这类问题，全新安装遇到的多半是前置条件不满足。

把这三个问题回答清楚，问题的范围就缩小了一大半。我见过太多人跳过这一步直接开搜，然后在一个和自己情况完全不相干的帖子里耗了两小时。

5.2 0x80096002 这类签名校验错误怎么处理

"安装程序无法安装 Windows PowerShell"配合一个负数错误码（比如-2146869246），是 WMF 5.1 在老系统上安装时最典型的失败形态。把那个负数错误码换算成十六进制看，会落在0x80096002这个区间，而这个区间属于签名与信任校验相关的错误类。

从这里的排查顺序应该是这样的：

# 校验安装包哈希，和官方公布的 SHA256 对比 Get-FileHash .\PowerShell-7.4.6-win-x64.msi -Algorithm SHA256 # 查看当前 .NET Framework 版本 Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full' | Select-Object Release, Version

这里我个人的经验是：绝大多数这类错误最后都落在"安装包不对"和"前置条件没打全"这两件事上，真正需要动证书库的情况很少。所以先花一分钟校验哈希值，比先花半小时搜错误码要高效得多。

顺便说一个容易忽略的点：.NET Framework 4.8 或更高版本已经安装这类提示和 PowerShell 的安装报错经常被混在一起看。这两个是完全不同的东西，前者是运行时的版本提示，后者是安装程序的报错。看到.NET Framework相关提示时先确认它是不是只是一个"已存在更高版本因此跳过"的信息性提示，别把它当成失败原因。

5.3 那些其实不是 PowerShell 的锅

有些现象看起来像是 PowerShell 升级引起的，实际上跟它没关系，排查方向错了会白费很多时间。

比如"电脑更新后 WiFi 图标没了"。这属于网络驱动的层面，和 PowerShell 版本没有任何关系，最多是同一个补丁日一起发生的两件事，被误认为有因果关系。判断方法很简单：看时间线。如果两件事发生在同一个时间窗口但属于不同的安装批次，基本可以判定无关。

再比如gpedit.msc打不开。这是组策略编辑器的组件状态问题，某些家庭版系统本来就不含这个组件，和 PowerShell 无关。有人会误以为是 PowerShell 开了ENABLE_PSREMOTING导致策略被锁，这个因果链是不成立的。

还有一类是脚本里的外部命令行为变了。比如某个 Python 工具在 PowerShell 里输出的中文乱码，改了 PowerShell 版本之后问题消失了——这不是"PowerShell 修好了"，而是新版默认 UTF-8 正好和那个工具的输出编码对上了。理解这一点很重要，因为下次换个工具可能又不对了，你还是得回到编码管线上看，而不是期待换个版本就能解决所有乱码。

提示：判断"是不是 PowerShell 引起的"，最快的办法是新建一个干净窗口，用pwsh -NoProfile启动，绕开所有 profile 配置跑一遍。如果干净窗口下问题不存在，那问题就在你的配置里，不在 PowerShell 本身。

6. 升级之外值得顺手做的三件配套事

版本号变了不等于活儿干完了。下面这三件事，做完能让后面几个月省下不少力气。

6.1 并行安装与回退的前提

在 Windows 上，5.1 和 7 天然并存，而 7 的多个小版本之间则不是并存关系——MSI 安装通常是原地覆盖。这意味着如果你想保留一个退路，得提前想清楚方案。

MSI 安装包默认不允许直接装一个更低版本去覆盖当前版本，所以"回退"这件事不能靠重装旧版实现。想回退，常规做法是先通过系统的"应用和功能"把当前版本卸载，再装旧版。商店版则由商店管理版本，不存在手动回退这个选项。所以如果你的环境对版本敏感，最稳妥的方案是别追求最新，锁在一个经过验证的版本上。

# 确认 5.1 和 7 各自是否可用，两者应同时存在且互不影响 Get-Command powershell.exe, pwsh.exe -ErrorAction SilentlyContinue | Select-Object Name, Source, Version # 分别查看两者的版本 powershell.exe -NoProfile -Command '$PSVersionTable.PSVersion' pwsh.exe -NoProfile -Command '$PSVersionTable.PSVersion'

能同时调出两个 exe 并打印出各自版本，说明并存状态是健康的。如果pwsh.exe找不到，说明 PATH 没配上，检查一下是不是安装时漏了ADD_PATH=1这个参数，或者装完没有重开终端。

6.2 升级后跑一遍模块体检

模块兼容性是跨大版本升级最容易出问题的环节。7 的模块清单里有一个PSEdition字段，标记它支持的运行环境。那些只标了Desktop的模块，在 7 下加载会失败或者行为异常。

# 列出当前可用的模块及其支持的环境 Get-Module -ListAvailable | Select-Object Name, Version, PSEdition | Sort-Object Name -Unique # 只挑出明确不支持 Core 的 Get-Module -ListAvailable | Where-Object { $_.PSEdition -and $_.PSEdition -notcontains 'Core' } | Select-Object Name, Version, PSEdition -Unique

第二段命令的输出就是你的待处理清单。处理思路有两条：一是找这个模块有没有支持 Core 的新版本，多数常用模块这几年都已经跟上了；二是如果确实没有新版，就把它留在 5.1 里跑，7 这边不要强行加载。

这里有个经验：不要因为模块不兼容就急着降级 PowerShell。模块的兼容性问题通常是局部可隔离的，一个模块用不了不代表整套环境不能用。把不兼容的活儿留在 5.1 里，新东西用 7 写，这是过渡期最务实的做法。

6.3 远程管理通道要单独确认

如果你的日常操作里有远程连到别的机器上执行命令的部分，那么升级之后这条通道需要单独验证一次，因为 7 的远程管理和 5.1 不是一回事。

MSI 安装时如果带了ENABLE_PSREMOTING=1，会做一部分准备工作，但服务端的监听是否真的起来了，还是要实测。最常见的两种连接方式是基于 WinRM 的和基于 SSH 的，前者是 Windows 原生那套，后者走标准 SSH 通道。

# 在目标机器上确认监听是否开启 Get-Service WinRM | Select-Object Name, Status, StartType # 在本地测试是否能建立会话 Test-WSMan -ComputerName <目标机器> # 用 7 显式发起一次远程会话，验证远端支持情况 pwsh -NoProfile -Command "Invoke-Command -ComputerName <目标机器> -ScriptBlock { \$PSVersionTable.PSEdition }"

最后那条命令返回的是Desktop还是Core很关键：它告诉你远端跑的是哪个版本。如果返回Desktop，说明远端环境里没有 7，或者远程终结点还指向 5.1，这时候你在本地用的新语法可能在远端认不出来。升级这种事儿在批量环境里从来不是一次到位的，先确认端到端的实际状态，再决定动作范围。

我踩过的一次坑就在这儿：本地升到 7 之后，脚本里用了一个 7 才有的运算符，本地跑得好好的，推送到远端全部失败。后来才发现远端还是 5.1。从那以后我在所有远程脚本的开头都加一行版本断言，不满足就直接退出并给出明确提示，而不是让它跑到一半失败、留下半截状态。

# 脚本开头的版本护栏 if ($PSVersionTable.PSVersion.Major -lt 7) { throw "此脚本需要 PowerShell 7 及以上，当前版本 $($PSVersionTable.PSVersion)" }

一行命令能搞定的事，前提是你知道自己站在哪块地面上。版本这种东西，装之前看清是哪一个，装完之后验证真的变了，比命令本身重要得多。