如果你手上有一台 Windows想给 PowerShell 更新一下最省事的做法真的就是一行命令winget install --id Microsoft.PowerShell --source winget。敲下去等进度条走完关掉窗口重开$PSVersionTable里的版本号就变了。整个过程不需要点下一步、不需要选安装路径、不需要在官网上一层层找下载链接。但这里面有个前提你得先搞清楚自己想更新的是哪一个 PowerShell。Windows 上同时存在两套 PowerShell——系统自带的 Windows PowerShell 5.1powershell.exe和独立发布的 PowerShell 7pwsh.exe。前者是操作系统组件压根不能用包管理器升级后者才是那条一行命令真正能搞定的目标。我见过太多人把这两件事搞混然后拿着一行winget命令去升级 5.1结果命令执行成功、版本号纹丝不动最后得出这条命令是骗人的这个结论。这篇内容就是把这行命令讲透它到底做了什么、什么场景下能用、参数为什么这么写、更新完之后哪些地方会跟着变、装不上时怎么一步步定位。看完你应该能在自己机器上、在同事的机器上、在几十台的内网机器上把这件事一次做对。1. 先分清你要更新的是哪一个 PowerShell这决定了那行命令长什么样动手之前花两分钟做一次身份确认比装完发现问题再回头查要划算得多。1.1 同一台机器上的两套 PowerShellpowershell.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.1pwsh.exe对应 7它们可以同时存在于一台机器上互不覆盖路径也完全不同。项目Windows PowerShell 5.1PowerShell 7.x可执行文件powershell.exepwsh.exe默认安装位置C:\Windows\System32\WindowsPowerShell\v1.0C:\Program Files\PowerShell\7是否系统组件是无法卸载否可独立安装卸载更新方式Windows 更新补丁包管理器 / MSI / 商店运行时.NET Framework.NET这张表是后面所有操作的基础。你在任务计划里写的是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.1Windows 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 Microsoft.PowerShell用包标识精确定位只写名字可能匹配到同名的其他包--source winget限定来源为社区源机器上配了多源时可能命中商店版--accept-package-agreements自动接受包许可首次安装会停下来等确认--accept-source-agreements自动接受源协议首次使用源会停下来等确认--silent静默安装不弹 UI会弹出 MSI 安装向导--disable-interactivity全程禁止交互提示脚本里可能卡死在某次询问--version 7.4.6锁定到指定版本永远拿最新企业环境可能不合规--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_PATH1 REGISTER_MANIFEST1 ENABLE_PSREMOTING1 USE_MU1 ENABLE_MU1这一串 MSI 属性名字很丑但它其实是把安装向导里的复选框搬到了命令行上ADD_PATH1把pwsh.exe目录写进 PATHREGISTER_MANIFEST1注册文件清单ENABLE_PSREMOTING1打开远程管理所需的监听USE_MU1和ENABLE_MU1让这个软件接受系统更新通道的管理。这四个开关默认是关的这就是为什么很多人手动点安装向导装完之后发现和winget装出来的行为不太一样。注意ENABLE_PSREMOTING1会动 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 官方提供三种包MSIPowerShell-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_MU1和ENABLE_MU1的作用——它把 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.1winget一定无效这属于用错工具不是安装失败。第二个问题包来源是什么社区源、商店源、还是手动下载的安装包。来源不同失败原因完全不一样。社区源的失败多半是网络访问问题或者源索引过期可以先跑winget source update商店源的失败多半是账户或者商店组件状态问题手动安装包的失败则集中在包完整性、系统前置条件、以及权限三件事上。第三个问题是全新安装还是覆盖升级覆盖升级会遇到已有更高版本文件被占用这类问题全新安装遇到的多半是前置条件不满足。把这三个问题回答清楚问题的范围就缩小了一大半。我见过太多人跳过这一步直接开搜然后在一个和自己情况完全不相干的帖子里耗了两小时。5.2 0x80096002 这类签名校验错误怎么处理安装程序无法安装 Windows PowerShell配合一个负数错误码比如-2146869246是 WMF 5.1 在老系统上安装时最典型的失败形态。把那个负数错误码换算成十六进制看会落在0x80096002这个区间而这个区间属于签名与信任校验相关的错误类。从这里的排查顺序应该是这样的排查项具体做法说明安装包完整性比对官网公布的哈希值下载中断或第三方重打包都会触发签名校验失败系统前置条件确认 .NET Framework 版本WMF 5.1 要求 4.5.2 以上实际建议直接升到 4.8系统补丁状态检查 SP 与必备补丁Win7 SP1 需要打全基础补丁和通用 C 运行库证书库状态确认系统根证书是否可用老系统长期未更新会缺根证书# 校验安装包哈希和官方公布的 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_PATH1这个参数或者装完没有重开终端。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_PSREMOTING1会做一部分准备工作但服务端的监听是否真的起来了还是要实测。最常见的两种连接方式是基于 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) }一行命令能搞定的事前提是你知道自己站在哪块地面上。版本这种东西装之前看清是哪一个装完之后验证真的变了比命令本身重要得多。