很多人的机器上还躺着系统自带的 Windows PowerShell 5.1每次打开都是一片蓝底白字敲个命令补全全靠 Tab 硬按脚本里写个还要报错。这时候同事甩过来一句装个 PowerShell 7 吧你搜了一圈发现安装方式五花八门有包管理器一行命令的有下载 MSI 双击下一步的还有解压个 zip 就能跑的。更麻烦的是卸的时候——控制面板里翻不到、装了两个版本不知道删哪个、PATH 里留着一行指向空目录的死路径。这篇就把 PowerShell 7 的安装和卸载从头到尾捋一遍包括版本通道怎么选、三种安装方式分别在什么场景下用、装完必须做哪几项配置、卸载时哪些残留必须手动清。不管你是刚接触命令行的新手还是已经写了几年脚本、想把手头环境统一起来的老手下面这些内容都能直接照着做。1. 动手之前先想清楚PowerShell 7 装的是什么1.1 版本号、发布通道与运行时依赖PowerShell 7 不是 Windows PowerShell 5.1 的补丁升级而是一次彻底的重写底层运行时从 .NET Framework 换成了跨平台的 .NET可执行文件名也从powershell.exe变成了pwsh.exe。这个改动带来的直接后果是——它可以在 Windows、Linux、macOS 上跑同一套脚本管道性能大幅提升ForEach-Object -Parallel这类并行能力也才有了实现基础。版本号的读法很关键。7.x 的第一位是主版本第二位是功能版本第三位是补丁版本。发布通道一般分三类长期支持版LTS、常规发布版、预览版Preview。长期支持版跟着 .NET 的 LTS 节奏走生命周期长适合生产环境和日常办公机器常规发布版功能更新快适合想尝鲜的开发者预览版则是给要提前验证兼容性的人用的接口随时可能变不建议装在主力机上。这里有个常被忽略的点不同大版本依赖的 .NET 运行时不一样。7.4 系列基于 .NET 87.5 系列基于 .NET 9。MSI 和包管理器安装时会把对应运行时一起带上但如果你是解压 zip 便携版就得自己确认机器上有没有匹配的运行时否则pwsh.exe双击就是一闪而过。我在一台老笔记本上就栽过这个跟头解压完直接运行窗口闪一下就没了折腾了半小时才发现是缺运行时。提示装之前先确定你要的是长期支持版还是常规发布版。两者可以共存但日常用建议只保留一个主版本避免脚本在不同机器的默认pwsh之间行为不一致。1.2 为什么它能和系统自带的 5.1 并存系统自带的 Windows PowerShell 5.1 装在C:\Windows\System32\WindowsPowerShell\v1.0下这个目录被大量系统组件、管理工具、安装程序依赖动它基本等于给自己找麻烦。PowerShell 7 的设计从一开始就考虑到了这点采用的是**并行安装side-by-side**策略独立目录、独立的可执行文件名、独立的模块路径、独立的配置文件路径。具体来说7 的默认安装目录是C:\Program Files\PowerShell\7可执行文件是pwsh.exe5.1 是powershell.exe。你在命令行里敲powershell打开的还是 5.1敲pwsh打开的才是 7。两者的 profile 文件也不在同一处7 的用户级 profile 在文档目录下的PowerShell文件夹里5.1 的在WindowsPowerShell文件夹里。模块搜索路径同样分开5.1 的模块不会自动出现在 7 里反之亦然。这种设计的价值在于迁移成本可控。你可以先在 7 里跑通新脚本遇到老脚本依赖某个只支持 .NET Framework 的模块随时切回 5.1 执行两边互不干扰。但代价也要认清这不是无缝过渡有些基于 .NET Framework 的老模块在 7 里根本加载不了需要找对应的新版本或者自己改写。1.3 五种安装方式的取舍对比网上的教程之所以让人看晕很大原因是每个人用的安装方式不同。实际常用的就这么几种各自的适用场景差别很明显安装方式适用场景优点局限系统包管理器个人日常、批量部署一条命令升级卸载都方便需要系统版本支持源里版本可能滞后MSI 安装包企业环境、需要精细控制参数齐全可静默、可定制右键菜单包体较大需手动下载ZIP 便携版免安装、U 盘携带、多版本并存解压即用不写注册表无自动升级PATH 需手工配脚本一键装新机器快速初始化省事需要信任脚本来源失败排查困难系统包仓库Linux服务器环境与系统更新体系统一仓库配置有门槛我个人的选择习惯是自己办公机用包管理器图省事给团队做镜像或者要交付给别人用的机器用 MSI 加静默参数行为可预期需要临时验证某个特定版本的行为直接解压 zip 到临时目录用完删目录就行不留痕迹。选择逻辑其实就一句话你要的是装一个长期使用的工具还是临时跑一个特定版本。前者优先选能被统一管理的安装方式后者选不污染系统的便携方式。搞清楚这一点后面具体的命令才有意义。2. 装前检查三分钟排掉八成隐患2.1 系统版本、架构与运行时确认PowerShell 7 对系统版本有明确门槛Windows 这边一般要求 Windows 10 1809 及以上服务器版对应 2019 及以上。低于这个版本不是说绝对装不上但会遇到各种奇怪的兼容问题不建议硬来。架构方面现在主流是 x64ARM 设备要选 arm64 包装错了虽然不一定立刻报错但运行时会走模拟层性能和部分原生模块都会受影响。确认方式很简单开一个 5.1 的窗口敲[System.Environment]::OSVersion.Version $env:PROCESSOR_ARCHITECTURE [System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture头一条给系统版本号第二条给进程架构第三条给操作系统架构。之所以要两条都看是因为在 ARM 机器上跑 x64 进程时$env:PROCESSOR_ARCHITECTURE会显示 AMD64容易误导。以第三条为准最稳妥。运行时这块如果你走 MSI 或包管理器安装程序会处理依赖基本不用操心。但如果机器上之前装过某个版本的 .NET 运行时又手动清理过可能出现版本注册信息残缺的情况表现为安装到一半回滚。这种时候先去应用和功能里看看有没有异常的运行时条目必要时修复或重装运行时再回来装 PowerShell。注意不要为了干净去手动删系统目录里的运行时文件夹。运行时的卸载必须走正规卸载流程手工删目录会留下注册表项后续安装会被判定为已存在但损坏卡在那里进退两难。2.2 现有环境扫描版本、PATH、执行策略装之前先摸清现状能省掉后面大量为什么版本不对的排查时间。三件事现在有哪些版本、PATH 里有什么、执行策略是什么。# 看当前会话版本 $PSVersionTable # 找机器上所有 pwsh 可执行文件 Get-Command pwsh -All | Select-Object Source, Version # 看 PATH 里跟 PowerShell 相关的项 $env:PATH -split ; | Where-Object { $_ -match PowerShell } # 看各作用域的执行策略 Get-ExecutionPolicy -List$PSVersionTable里重点看PSEdition值是Core说明是 7是Desktop说明是 5.1。如果 PATH 里出现了多个指向不同版本目录的条目那就是隐患命令解析按 PATH 顺序走靠前的先命中你以为打开的是新版实际跑的是旧版。这种情况我见过不止一次尤其是先装 zip 版后来又装 MSI 的机器两个目录都在 PATH 里结果pwsh -v显示的版本和预期对不上。执行策略也顺便看一眼。5.1 时代很多人把策略改成了Unrestricted这个设置是分作用域的7 默认继承的是Restricted或RemoteSigned脚本一跑就报禁止运行脚本。提前知道现状装完直接按需设置不用临时抓瞎。2.3 权限、杀软与离线环境的处理安装类操作基本都需要管理员权限。Windows 上右键以管理员身份运行是最省事的做法但要注意如果你是从网络位置或者压缩包里直接双击安装包可能触发系统的来自其他计算机的文件标记导致安装程序被拦截或者解压出问题。稳妥做法是先把安装包完整复制到本地磁盘再执行。安全软件的干扰是安装失败的高发原因。某些实时防护会对安装程序的解压释放行为敏感表现为安装进度条卡住、报 1603 错误、或者装完发现文件不全。判断方法很直接看安全软件的拦截日志里有没有对应时间点的记录。如果有临时把安装目录加进白名单再装装完把白名单撤掉——不要图省事一直挂着那等于给自己开了个长期口子。离线环境要单独说。没有外网的机器包管理器和在线脚本都用不了只能用离线安装包。这里的关键是依赖完整MSI 包本身自带运行时可以直接用zip 包不带运行时得提前把对应版本的运行时离线包一起准备好。另外离线机器上通常没有配置模块仓库源装完之后Install-Module会失败这个在规划阶段就要想到把常用模块也一并离线下载好。3. Windows 上的三条安装路线实操3.1 包管理器一条命令推荐日常系统自带的包管理器是最省心的路径前提是系统版本够新。先搜一下确认包标识别硬记winget search powershell输出里会列出几个条目注意区分正式版和预览版标识里带Preview字样的就是预览通道。确认之后执行安装把搜索到的标识填进去winget install --id 搜索到的包标识 --source winget如果你要指定某个具体版本加--version参数想装完立刻用新版本覆盖当前会话加--silent走静默安装更干净。装完不需要重启但已经打开的终端窗口不会自动生效因为 PATH 是在进程启动时读取的。关掉重开一个窗口敲pwsh -v验证。升级同样是这条路径winget upgrade --id 包标识这里有个实操细节值得说包管理器安装的版本和源里同步存在时间差源里更新晚几天是常态。急着用新版本的话还是得走 MSI 或者直接下 zip。另外包管理器安装默认会写 PATH、注册文件关联和右键菜单行为跟 MSI 基本一致卸载时也是走同一套注册信息比较规范。提示如果你的机器上装了多个包管理器系统自带的、第三方的尽量只用其中一个来管理 PowerShell混用容易出现一个认为装了、另一个认为没装的尴尬局面卸载时尤其麻烦。3.2 MSI 安装包图形与静默参数全解MSI 是控制力最强的方式适合需要精确控制安装行为的场景。图形化安装没什么好说的下一步到底但有几个勾选项值得停下来看一眼添加到 PATH默认勾选。取消的话装完必须用完整路径调用一般不推荐取消。启用 PowerShell 远程处理会配置 WinRM 相关设置。只在需要远程管理的机器上勾普通办公机勾上等于多开了一个服务面。注册资源管理器右键菜单装了之后在文件夹上右键能直接在此处打开 PowerShell挺方便但有些企业的终端管理策略会把这个菜单项屏蔽掉。文件右键使用 PowerShell 运行跑单个脚本时有用但误点风险也高看个人习惯。真正体现价值的是静默安装参数。批量部署时用得上msiexec /i PowerShell-7.x.x-win-x64.msi /qn /norestart ADD_PATH1 REGISTER_MANIFEST1 ENABLE_PSREMOTING0 ADD_EXPLORER_CONTEXT_MENU_OPENPOWERSHELL1/qn是全静默无任何界面/norestart抑制自动重启后面几个大写属性对应界面上的勾选项1为启用0为禁用。写部署脚本时把这些显式声明出来比依赖默认值靠谱得多——默认值会随版本变化显式声明才是可复现的。安装日志建议打开出问题时这是唯一的线索来源msiexec /i PowerShell-7.x.x-win-x64.msi /qn /l*v %TEMP%\pwsh-install.log日志文件动辄几 MB别看全文直接搜Return value 3这是 MSI 标记失败动作的标准写法往上下各看几十行就能定位到具体哪一步挂了。3.3 ZIP 便携版解压即用与 PATH 手工挂载便携版适合三种人没管理员权限的、需要多版本并存的、只想临时试一下的。流程是下载对应架构的 zip 包解压到一个你记得住的目录比如D:\Tools\pwsh-7然后直接运行目录里的pwsh.exe。想让它变成全局可用得手工挂 PATH。用户级 PATH 不需要管理员权限$target D:\Tools\pwsh-7 $userPath [Environment]::GetEnvironmentVariable(PATH, User) if ($userPath -notlike *$target*) { [Environment]::SetEnvironmentVariable(PATH, $userPath;$target, User) }这段逻辑里加了个去重判断因为重复执行会把同一条路径反复追加PATH 越滚越长早晚撞上长度限制。改完 PATH 必须重开终端。便携版的坑主要集中在两点。第一是运行时依赖前面提过zip 包不带运行时机器上没有匹配版本的话pwsh.exe直接闪退用命令行启动能看到具体报错。第二是没有文件关联和右键菜单.ps1文件双击还是用记事本打开这是预期行为不是装坏了。如果你确实需要这些集成还是老老实实用 MSI。多版本并存是便携版的杀手级用法。解压两三个不同版本的目录分别起名pwsh-7.4、pwsh-7.5验证脚本兼容性时直接调对应目录下的可执行文件互不干扰验证完删目录即可系统里一点痕迹都不留。3.4 装完必须跑的验证清单装完不验证等于没装。下面这几条一次跑完能覆盖绝大多数安装异常# 1. 版本与版本类型 $PSVersionTable | Format-List # 2. 可执行文件位置确认没跑到旧版本 Get-Command pwsh | Select-Object Source # 3. 模块路径是否指向新目录 $env:PSModulePath -split ; # 4. 基础功能自检 Get-ChildItem $PSHOME | Measure-Object Get-Help Get-Process -Examples | Select-Object -First 5第一条里PSEdition必须是CoreVersion是 7 开头。第二条确认路径指向你刚装的位置如果是 zip 版的旧目录说明 PATH 顺序有问题。第三条看模块路径里有没有新版本自己的 Modules 目录没有的话后面装模块会找不到位置。第四条是功能性验证Get-Help能出内容说明帮助文件完整有些精简安装会漏掉帮助内容。还有个容易被忽略的检查文件签名。从非官方渠道拿到的安装包装之前就该验一下Get-AuthenticodeSignature D:\Downloads\PowerShell-7.x.x-win-x64.msi | Format-List Status, SignerCertificateStatus是Valid才继续。这条不是形式主义命令行工具的运行权限很高来源不明的包风险不小。4. Linux 与 macOS 的安装路径4.1 Linux二进制包与发行版包管理器Linux 上的安装逻辑跟 Windows 差别很大核心是解压到固定位置 建符号链接。官方提供的是 tar.gz 二进制包通用做法# 下载后解压到指定目录 sudo mkdir -p /opt/pwsh/7 sudo tar -xzf powershell-7.x.x-linux-x64.tar.gz -C /opt/pwsh/7 # 建符号链接让 pwsh 全局可用 sudo ln -sf /opt/pwsh/7/pwsh /usr/bin/pwsh # 验证 pwsh -v符号链接这一步是关键。不建链接的话每次都得敲完整路径脚本里写 shebang 也没法用。用ln -sf里的-f是为了覆盖已有链接升级时直接重跑这段就行不用先删旧的。发行版自己的包管理器也能装通常是.deb或.rpm包。这种方式的好处是纳入系统包管理体系升级卸载都跟其他软件一致坏处是仓库里的版本往往比官方发布晚而且不同发行版的打包方式有差异。跑长期服务的机器建议用这种方式便于统一运维开发机想用新特性还是 tar.gz 直接解压更痛快。依赖方面Linux 上的 PowerShell 需要一些基础库主流发行版基本都预装了。极简镜像比如容器基础镜像里可能缺表现为启动时报找不到某个.so文件。这种时候用ldd看一下依赖树缺什么补什么别去猜。4.2 macOS包管理器与 pkg 两条路macOS 上有两条主流路径。第一条是用第三方包管理器命令简洁升级卸载一条命令搞定brew install --cask powershell用 cask 是因为 PowerShell 提供的是应用形式的安装包不是普通的命令行 formula。升级用brew upgrade --cask powershell卸载用brew uninstall --cask powershell这些都由包管理器接管不用自己清残留。第二条路是下载 pkg 安装包双击安装。这种方式会把文件装到/usr/local/下面并在/usr/local/bin里建链接。适合不想装包管理器的机器或者企业环境统一分发。卸载时不能只把应用拖进废纸篓得走 pkg 的卸载流程否则链接和配置文件都会留下。Apple Silicon 和 Intel 芯片的包是分开的下载时注意选对架构。装错了虽然能通过 Rosetta 转译运行但启动速度明显变慢而且某些依赖原生库的模块会加载失败。4.3 跨平台安装后的统一验证三个平台装完之后验证的落脚点其实是同一套$PSVersionTable $PSHOME [System.Runtime.InteropServices.RuntimeInformation]::OSDescription$PSHOME给出安装根目录Linux 上应该是/opt/pwsh/7之类macOS 上是应用包里的路径。这个变量在写跨平台脚本时很有用——需要读取安装目录下的资源文件时用它拼路径比硬编码安全得多。跨平台场景还有个坑默认编码和换行符。Windows 上默认可能是 UTF-16 或带 BOM 的 UTF-8Linux/macOS 上是无 BOM 的 UTF-8。同一份脚本在两个平台跑中文输出可能一个正常一个乱码。这不是安装问题但装完跨平台环境后很快就会撞上提前把脚本文件统一存成无 BOM 的 UTF-8 能省不少事。5. 装完别急着用四项必做配置5.1 Profile 文件分层与路径Profile 是 PowerShell 启动时自动执行的脚本相当于命令行的开机启动项。它分好几个作用域路径各不相同作用域适用对象典型用途CurrentUserCurrentHost当前用户 当前宿主个人别名、提示符定制CurrentUserAllHosts当前用户 所有宿主环境变量、函数库AllUsersCurrentHost所有用户 当前宿主团队统一的宿主配置AllUsersAllHosts所有用户 所有宿主机器级基础配置查看实际路径用$PROFILE | Format-List *一次列出全部四个。新手最常犯的错是把内容写进了AllUsersAllHosts结果影响了机器上所有用户包括服务账户排查起来很费劲。个人配置一律写在CurrentUserAllHosts里这个位置最不容易出事。创建 profile 的正确姿势是先判断存在性再创建不要直接覆盖if (-not (Test-Path $PROFILE.CurrentUserAllHosts)) { New-Item -ItemType File -Path $PROFILE.CurrentUserAllHosts -Force } notepad $PROFILE.CurrentUserAllHosts注意profile 里不要放耗时操作比如网络请求、大目录扫描。每次开终端都执行一遍几秒钟的延迟积累起来很影响体验。需要预加载的数据放到按需调用的函数里。5.2 PSReadLine 与命令行体验从 5.1 换到 7 的人第一感受往往是补全变聪明了这背后是 PSReadLine 模块。7 自带这个模块但默认配置比较保守几个开关打开后体验会明显不同Set-PSReadLineOption -PredictionSource History Set-PSReadLineOption -PredictionViewStyle ListView Set-PSReadLineOption -EditMode Windows Set-PSReadLineKeyHandler -Key Tab -Function MenuComplete第一条启用基于历史记录的预测输入时会灰显提示你之前敲过的完整命令按右方向键直接采纳。第二条把预测结果改成列表展示候选多的时候比单行提示清楚。第三条保持 Windows 的编辑习惯习惯 Emacs 键位的可以改成Emacs。第四条把 Tab 改成菜单式补全比默认的循环补全好用得多。这几行写进 profile 就长期生效。不过要留意版本差异不同版本的 PSReadLine 支持的参数不完全一样某些新参数在老版本上会报找不到参数。写进 profile 前先在当前会话里逐条试一遍能过再落盘否则下次开终端直接一片红字。5.3 执行策略、模块仓库与签名执行策略是脚本能不能跑的总开关。7 默认比 5.1 严格第一次跑.ps1很可能就撞上禁止运行脚本。改之前先想清楚范围# 只改当前用户影响面最小 Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned # 确认各作用域现状 Get-ExecutionPolicy -ListRemoteSigned的含义是本地写的脚本直接跑从网络下载的脚本必须有有效签名。这个平衡点在日常使用中比较合适。改成Unrestricted或者Bypass确实什么都能跑但也意味着任何来源的脚本都能在你机器上执行任意操作风险自己掂量。模块仓库这边7 默认指向公共的模块库。装模块前先确认源配置Get-PSRepository Find-Module -Name PSReadLine Install-Module -Name 模块名 -Scope CurrentUser -Repository PSGallery-Scope CurrentUser装到用户目录不需要管理员权限也不会污染系统级目录。企业内网环境通常有自己的内部源用Register-PSRepository注册后把默认源换掉避免每次装模块都往外网跑。签名验证这块自己写的脚本如果要在团队内分发建议加个自签名证书不然每台机器都要单独改策略。用New-SelfSignedCertificate生成证书Set-AuthenticodeSignature给脚本签名再把证书导入到目标机器的受信任发布者存储里。流程稍长但一次配好后面分发省事。5.4 终端与应用集成新版 PowerShell 装完很多人的终端里默认还是 5.1得手动切。Windows Terminal 里的做法是打开设置找到启动里的默认配置文件把它改成 PowerShell 7 对应的那一项。改完新开的标签页就是 7 了。这一步不做你会经常在我以为我在用新版和怎么这个语法不支持之间反复横跳。右键菜单的集成情况取决于安装方式。MSI 安装时勾了对应选项才会有便携版没有。想要的话可以手工加注册表项但不建议新手折腾改错了影响资源管理器稳定性。真需要频繁在某个目录下开终端直接从终端里cd过去更简单。还有个实用技巧是把常用目录做成快捷函数放进 profilefunction work { Set-Location D:\Projects\current } function logs { Set-Location $env:LOCALAPPDATA\Temp }比记一长串路径靠谱也比频繁用鼠标点目录快。6. 卸载比安装更容易留尾巴6.1 卸载前的三项检查卸载前先做三件事能避免大部分卸不干净的问题。第一确认没有进程占用。开着的pwsh窗口、后台跑的脚本、被 VS Code 之类编辑器挂载的终端会话都会锁住安装目录里的文件导致卸载程序报文件正在使用。用Get-Process pwsh看一眼全部关掉再动手。第二备份 profile。用户级 profile 文件默认不在安装目录里卸载程序一般不会删但有些清理工具会顺手带走。里面有你的别名、函数、环境变量设置丢了重写很痛苦。直接复制一份到别的目录几秒钟的事。第三记下安装方式和安装位置。这决定了你该用哪种卸载方法。查安装位置Get-Command pwsh -All | Select-Object Source, Version如果输出里只有一个路径且在Program Files下基本是 MSI 或包管理器装的如果在你自己选的目录下就是 zip 版如果出现多个路径说明装过不止一次需要逐个处理。6.2 Windows包管理器、MSI 与 ZIP 三种卸载包管理器装的一条命令解决winget list --name PowerShell winget uninstall --id 包标识先list确认标识和版本再uninstall别凭记忆敲标识拼错了会提示找不到包白折腾。MSI 装的优先走应用和功能里的卸载入口行为最标准。命令行方式# 从注册表里找到产品码 Get-ItemProperty HKLM:\SOFTWARE\Classes\Installer\Products\* | Where-Object { $_.ProductName -like *PowerShell* } | Select-Object ProductName, PSChildName拿到产品码后用msiexec /x {产品码} /qn静默卸载。注意这里的产品码格式是紧凑的 GUID跟常见的带大括号格式不一样转换规则是把每 8 位一组倒序重排——嫌麻烦的话直接用安装包反向执行msiexec /x 安装包路径更省事。ZIP 版的卸载本质就是删目录加清 PATH$target D:\Tools\pwsh-7 Remove-Item $target -Recurse -Force $userPath [Environment]::GetEnvironmentVariable(PATH, User) $newPath ($userPath -split ; | Where-Object { $_ -and $_ -ne $target }) -join ; [Environment]::SetEnvironmentVariable(PATH, $newPath, User)删目录前务必确认$target变量指向正确。我见过有人变量写错把整个 Tools 目录端了里面还有其他工具。稳妥做法是先Get-ChildItem $target看一眼内容确认是这个版本的安装目录再删。6.3 Linux 与 macOS 的清理Linux 上 tar.gz 装的卸载就是反向操作sudo rm -rf /opt/pwsh/7 sudo rm -f /usr/bin/pwsh符号链接一定要单独删只删目录的话/usr/bin/pwsh会变成一个悬空链接之后敲pwsh报没有那个文件或目录看着像没删干净。用ls -l /usr/bin/pwsh确认链接已消失。包管理器装的用对应命令卸载deb 系是sudo apt remove 包名rpm 系是sudo dnf remove 包名把配置也一起清掉的话加--purge或--remove-purge之类的参数具体看发行版。macOS 上 brew 装的用brew uninstall --cask powershellpkg 装的用sudo pkgutil --forget 包标识配合删除/usr/local/下的相关目录。配置文件目录在各平台的位置不同但都值得单独检查一遍# 用户级配置目录卸载后可能残留 $env:LOCALAPPDATA $HOME/.config/powershell里面是历史记录、profile、模块缓存。想彻底清净就一起删但删之前确认里面没有你还想保留的 profile 内容。6.4 残留清单与卸载后验证卸载完成后按下面这张清单逐项确认检查项检查方式正常状态可执行文件Get-Command pwsh -All报错找不到命令PATH 变量$env:PATH -split ;无相关目录安装目录Test-Path C:\Program Files\PowerShellFalse用户配置目录Test-Path $env:LOCALAPPDATA\PowerShell按需保留或删除右键菜单文件夹上右键无相关菜单项文件关联双击.ps1文件不再关联到 pwsh计划任务/服务Get-ScheduledTask过滤无残留条目PATH 里残留是最常见的。卸载程序不一定能清干净尤其是装过多个版本又手动改过 PATH 的机器。残留的危害不在于占地方而在于你以后重装时命令可能仍然解析到那个已经不存在的路径报错信息还特别迷惑。验证一句话搞定开一个新终端敲pwsh应该是无法将 pwsh 项识别为 cmdlet这类报错。能打开就说明没卸干净回去接着查。7. 常见问题速查与排查思路7.1 版本、路径类问题装完敲pwsh提示找不到命令。九成是 PATH 没生效。先确认安装目录存在再检查 PATH 里有没有对应条目最后确认终端是新开的。如果 PATH 里明明有命令还是找不到用where.exe pwsh看系统实际解析到了哪里有时候是另一个同名程序把位置占了。敲pwsh -v显示的版本跟装的不一致。PATH 里有多个条目靠前的那个是旧的。用Get-Command pwsh -All列出全部把不需要的从 PATH 里剔掉顺序也要调整到新版本在前。脚本里的powershell调用跑的还是 5.1。这是预期行为powershell.exe和pwsh.exe是两个不同的程序。老脚本里硬编码了powershell的要么改脚本要么加个包装函数做映射。批量改脚本时用正则替换但改完必须逐个跑一遍有些脚本依赖 5.1 特有的行为硬迁过去会出问题。7.2 安装失败类问题MSI 安装报 1603。这是最泛化的错误码含义是安装过程中发生致命错误本身不说明原因。必须看日志搜Return value 3定位到具体动作。常见成因有三个目录权限不足、旧版本残留导致状态冲突、安全软件拦截文件写入。按这个顺序排查命中率最高。报 2502/2503。这两个码跟 MSI 服务的权限上下文有关典型出现在通过某些远程会话或者受限账户执行安装时。解决办法是把安装包放到本地磁盘用管理员身份从命令行执行msiexec不要在压缩包里直接双击。安装进度卡在某个百分比不动。先别急着结束进程给它几分钟。真卡死了就取消清理临时目录后重来。反复卡在同一位置的多半是安全软件在逐个扫描释放的文件把安装目录加白名单再试。装完提示缺少某个 DLL。运行时依赖没装全。MSI 一般不会出现zip 版常见。去系统事件查看器里找应用错误日志会明确写出缺哪个文件装对应的运行时包即可。7.3 启动与模块类问题pwsh启动一闪而过。命令行里执行能看到具体报错缺运行时、profile 里有语法错误、或者杀软把某个依赖文件隔离了。先加-NoProfile参数排除 profile 因素pwsh -NoProfile能正常启动就说明是 profile 的问题逐段注释排查。模块加载报未能加载文件或程序集。这是典型的 .NET Framework 模块在 7 上不兼容。用Get-Module -ListAvailable看模块的兼容性标记PSEdition里没有Core的就是不支持的。解决办法是找该模块的新版本或者改用 5.1 执行相关逻辑。中文输出乱码。控制台代码页和脚本编码不一致。7 默认用 UTF-8老脚本可能是 GBK 编码保存的。用Get-Content -Encoding显式指定读或者把脚本文件另存为 UTF-8。终端本身也要设成 UTF-8 代码页两者得对上。7.4 卸载类问题现象可能原因处理方式应用列表里找不到卸载项zip 版安装未注册直接删目录 清 PATH卸载报文件被占用有 pwsh 进程或编辑器挂载关进程必要时重启卸载后右键菜单还在注册表项未清手动删对应注册表键卸载后重装失败注册表残留产品信息用官方清理工具或手工清注册表卸载后 PATH 报错PATH 里有悬空路径编辑 PATH 删掉无效项卸载后 5.1 打不开误删了系统组件用系统文件检查工具修复表格最后一条要特别提醒5.1 的目录在系统目录下手工删文件极容易误伤。清理时严格限定在你确认属于 7 的路径上不要图省事整目录删除。8. 几条踩坑心得装和卸这件事真正费时间的从来不是那几条命令而是环境里那些看不见的历史包袱。我自己反复撞过的几件事写下来给后来人省点功夫。一是永远先摸清现状再动手。拿到一台机器先跑一遍版本、PATH、执行策略的检查比装完出问题再回头查快得多。尤其是接手的别人用过的机器PATH 里可能躺着三四个历史版本路径你以为的全新安装其实是第四个版本。二是安装日志比搜索引擎有用。MSI 的/l*v日志、包管理器的详细输出、事件查看器里的应用错误这三处基本能覆盖所有安装失败的原因。养成开日志的习惯出问题时不用靠猜。三是卸载比安装更值得做笔记。装的时候都是标准流程卸的时候每个人机器上的残留都不一样。我自己维护了一个小清单记录每台机器上 PowerShell 的安装方式、路径、特殊配置换机器或者交接时直接照单清理比现场摸索快十倍。四是多版本共存不是坏事但要管住默认值。开发和验证阶段留两三个版本很正常关键是 PATH 顺序和默认终端配置要明确别让自己都搞不清当前敲的命令跑的是哪一版。给每个版本的启动加个明显的提示符标记比如在 profile 里把 prompt 加上版本号前缀一眼就能分辨。