1. 为什么要折腾 PowerShell 7 这件事

如果你在 Windows 上做过一段时间的自动化脚本、批量运维或者日常开发环境搭建，大概率绕不开 PowerShell。系统自带的那个蓝色窗口，版本号常年停在 5.1，功能上够用，但一旦你开始写稍微复杂一点的脚本，就会陆续撞上几个让人难受的墙：并行处理能力弱、JSON 处理别扭、跨平台兼容性差、管道性能一般，还有那个让人又爱又恨的 Windows PowerShell 与 PowerShell Core 两套体系并存的混乱局面。

PowerShell 7 就是在这个背景下出现的。它基于 .NET 平台重构，支持 Windows、Linux、macOS 三端统一，带来了ForEach-Object -Parallel并行管道、更好的 JSON 与 CSV 处理、更现代的语法特性，以及一个非常关键的能力——可以真正意义上替代系统自带的 5.1 成为默认终端环境。这件事听起来简单，但实际操作中涉及安装方式选择、PATH 环境变量调整、默认配置文件迁移、执行策略处理、旧模块兼容性排查等一系列细节，稍不注意就会出现“装完了但打开还是 5.1”或者“脚本跑一半报模块找不到”的尴尬情况。

这篇内容面向的是有一定 Windows 使用基础、写过简单脚本、希望把开发或运维环境统一到 PowerShell 7 的同学。不管你是刚接触 PowerShell 的新手，还是已经在 5.1 上积累了一堆脚本想平滑迁移的老手，下面这套流程和踩坑经验都能直接拿去用。我会把每一步背后的原因讲清楚，把参数选择的逻辑摊开，把实际会遇到的问题和排查思路整理成可查的表，尽量让你少走弯路。

2. 升级前的整体思路与方案选型

2.1 先搞清楚 5.1 和 7 的关系，别急着卸载

很多人第一反应是“升级”，想着把旧的 5.1 干掉换成 7。这个思路是错的，而且很危险。Windows PowerShell 5.1 是系统组件的一部分，大量系统管理功能、组策略脚本、部分企业环境的管理工具都依赖它，强行移除会引发一系列连锁问题。正确的理解是：PowerShell 7 是独立安装的并行版本，它与 5.1 共存，通过调整调用优先级让它成为你日常使用的默认入口。

这个设计其实很聪明。5.1 继续作为系统底层保障存在，7 作为你日常操作的现代化环境。两者可以同时存在，互不干扰。你在 7 里跑脚本，遇到某些只兼容 5.1 的老模块时，还可以临时切回去执行。所以整个方案的核心不是“替换”，而是“共存 + 优先级调整”。

理解这一点之后，后面的所有操作逻辑就顺了：安装 7 到独立目录，把它的路径放到 PATH 靠前的位置，配置好默认的 profile，让新开的终端自动进入 7 的环境。整个过程不碰系统自带的 5.1，风险可控。

2.2 安装方式怎么选：三种路径的取舍

PowerShell 7 在 Windows 上有几种主流安装方式，每种适合不同场景，选错了后面维护会很难受。

我个人的建议是：日常开发机优先用 winget，受限或需要精确控制版本的环境用 ZIP 便携包，完全不想碰命令行的用 MSI。winget 的好处是升级时一条winget upgrade就能搞定，省去反复下载安装包的麻烦。ZIP 包适合那种公司电脑权限受限、或者你想同时保留多个 7.x 版本做兼容测试的场景。

这里有个细节值得说：不管你用哪种方式，安装路径尽量保持默认或者统一规划。MSI 默认装到C:\Program Files\PowerShell\7，ZIP 包你自己解压到某个固定目录。路径统一之后，后面配置 PATH 和排查问题都会省心很多。

2.3 为什么必须处理 PATH 和执行策略

装完之后最常见的两个“装了个寂寞”问题，一个是 PATH 没配好导致命令行敲pwsh找不到或者还是进 5.1，另一个是执行策略拦住了脚本运行。这两个点必须在安装后立刻处理，否则你会以为装失败了。

PATH 的逻辑是这样的：系统在命令行输入一个命令时，会按 PATH 里目录的顺序依次查找可执行文件。PowerShell 7 的可执行文件名是pwsh.exe，而 5.1 是powershell.exe，两者名字不同，所以严格来说不会直接冲突。但如果你希望某些场景下用powershell这个命令也能进 7，或者你的工具链里写死了调用powershell，那就需要额外处理。大多数情况下，我们只需要保证pwsh能被正确找到，并且在终端配置里把默认启动项指向它。

执行策略则是另一回事。PowerShell 默认对脚本执行有安全限制，7 里默认策略通常是RemoteSigned，本地写的脚本能跑，但从网络下载的脚本需要签名。如果你从别处拷贝了脚本过来跑，可能会被拦。这个策略的调整要谨慎，后面实操部分我会给出具体命令和取舍建议。

3. 核心实操：从安装到设为默认的完整流程

3.1 用 winget 安装 PowerShell 7 的完整命令

先确认 winget 可用。打开现有的 PowerShell 窗口（5.1 也行），执行：

winget --version

能输出版本号就说明可用。接着搜索一下 PowerShell 的包：

winget search Microsoft.PowerShell

你会看到类似Microsoft.PowerShell的条目，对应的是稳定版。安装命令：

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

这里几个参数解释一下。--id指定精确的包标识，避免装错；--source winget明确从 winget 源拉取，防止命中其他源的同名包。安装过程中 winget 会自动处理下载、校验、安装和 PATH 配置，全程无需手动干预。

装完之后必须新开一个终端窗口，因为 PATH 的变更对已经打开的窗口不生效。新窗口里执行：

pwsh -v

如果输出PowerShell 7.x.x这样的版本号，说明安装成功且 PATH 已生效。这一步是验证的关键，很多人装完在旧窗口里试，发现还是 5.1，就以为失败了，其实只是环境变量没刷新。

提示：如果pwsh -v提示找不到命令，先别急着重装。关掉所有终端窗口重新开一个，或者手动检查 PATH 里是否包含 PowerShell 7 的安装目录。winget 安装有时需要注销重登才能完全刷新环境变量。

3.2 ZIP 便携包方式的手动配置

如果你的环境不能用 winget，或者需要精确控制版本，ZIP 包是可靠选择。从官方发布页下载对应架构的 zip（一般选 x64），解压到一个固定目录，比如C:\Tools\PowerShell\7。

解压后目录里应该有pwsh.exe。接下来手动把它加入 PATH。用系统属性界面操作比较直观：右键“此电脑” → 属性 → 高级系统设置 → 环境变量 → 在“用户变量”或“系统变量”里找到Path→ 编辑 → 新建 → 填入C:\Tools\PowerShell\7→ 一路确定。

用命令行也能改，但涉及注册表操作，这里给一个相对安全的用户级 PATH 追加方式（在 5.1 里执行）：

$userPath = [Environment]::GetEnvironmentVariable("Path", "User") $newEntry = "C:\Tools\PowerShell\7" if ($userPath -notlike "*$newEntry*") { [Environment]::SetEnvironmentVariable("Path", "$userPath;$newEntry", "User") }

这段逻辑先读取当前用户级 PATH，判断目标目录是否已存在，不存在才追加，避免重复写入导致 PATH 越来越长。改完同样要新开窗口验证。

注意：ZIP 包方式不会自动创建开始菜单快捷方式，也不会注册卸载信息。如果你需要这些，还是走 MSI 或 winget 更省事。便携包的价值在于可控和可移植，比如放在 U 盘里带着走。

3.3 把 PowerShell 7 设为终端默认启动项

装好并能用pwsh启动之后，下一步是让日常打开终端时默认进 7，而不是每次手动敲pwsh。这取决于你用的是什么终端入口。

Windows Terminal 用户：这是最现代也最推荐的方式。打开 Windows Terminal，点标签栏旁边的下拉箭头 → 设置 → 在“启动”里找到“默认配置文件”，把它改成 PowerShell 7 对应的条目。保存后新开的标签页就直接是 7 了。Windows Terminal 通常会自动识别已安装的 PowerShell 7，如果没识别到，可以在配置文件列表里手动添加，命令填pwsh.exe。

传统控制台/快捷方式用户：如果你习惯用 Win+R 输入powershell或者点开始菜单的旧图标，那进的还是 5.1。要改这个，可以创建一个新的快捷方式，目标填C:\Program Files\PowerShell\7\pwsh.exe，放到桌面或任务栏。更彻底的做法是调整环境变量里powershell.exe的解析优先级，但这个操作有风险，可能影响依赖 5.1 的系统脚本，不建议普通用户折腾。

IDE 和编辑器集成：VS Code 里可以在设置中搜索terminal.integrated.defaultProfile.windows，把它设为PowerShell（VS Code 会自动关联到 7）。其他编辑器类似，找到终端配置项指向pwsh.exe即可。

3.4 迁移 profile 配置文件

5.1 和 7 的 profile 文件路径不同，这是很多人升级后觉得“我的别名和函数都没了”的原因。5.1 的 profile 一般在Documents\WindowsPowerShell\下，7 的在Documents\PowerShell\下。

先看看 7 的 profile 路径：

$PROFILE

它会输出类似C:\Users\你的用户名\Documents\PowerShell\Microsoft.PowerShell_profile.ps1的路径。如果这个文件不存在，可以创建：

if (-not (Test-Path $PROFILE)) { New-Item -ItemType File -Path $PROFILE -Force }

然后把 5.1 里你积累的别名、函数、环境变量设置迁移过来。不要直接整个文件复制，因为有些语法或模块在 7 里可能不兼容。建议逐段迁移，迁一段测一段。常见的别名定义、简单的函数基本都能直接用，涉及特定模块加载的部分要重点验证。

实操心得：迁移 profile 时，我习惯先在 7 里手动执行一遍 5.1 profile 里的每一段，确认没问题再写进文件。这样能快速定位是哪一段导致的报错，比整文件搬过去再排查高效得多。

3.5 执行策略的合理设置

查看当前策略：

Get-ExecutionPolicy -List

会列出多个作用域（MachinePolicy、UserPolicy、Process、CurrentUser、LocalMachine）的策略。优先级从高到低。一般改CurrentUser作用域就够了，影响范围可控：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

RemoteSigned的含义是：本地编写的脚本可以直接运行，从网络来源的脚本需要数字签名。这个策略在安全性和便利性之间比较平衡，适合大多数开发和运维场景。不建议无脑设成Unrestricted或Bypass，那等于把安全门完全敞开。

如果你确实需要跑一些来源可信但没有签名的脚本，更稳妥的做法是用Unblock-File解除单个文件的锁定，而不是全局放宽策略：

Unblock-File -Path .\某个脚本.ps1

这样只对特定文件放行，整体策略保持不变。

4. 兼容性排查与模块迁移的实战细节

4.1 旧模块在 7 里跑不动的典型表现

PowerShell 7 基于 .NET Core/.NET 5+，而 5.1 基于 .NET Framework，这个底层差异导致部分老模块在 7 里加载失败。典型表现是Import-Module时报错，提示程序集版本不匹配、类型找不到，或者模块清单里声明了不兼容的 PowerShell 版本范围。

排查的第一步是看模块兼容性。7 提供了一个实用命令：

Get-Module -ListAvailable | Where-Object { $_.CompatiblePSEditions -notcontains 'Core' }

这条命令列出所有没有声明支持 Core 版本的模块，这些就是潜在的风险点。注意是“潜在”，不是“一定不能用”，有些模块虽然没声明但实际能跑，需要实测。

对于确实不兼容的模块，有几个处理方向。一是找该模块的新版本，很多主流模块已经发布了支持 7 的版本。二是用 Windows PowerShell 兼容性会话，在 7 里通过Import-Module -UseWindowsPowerShell把模块加载到一个隐式的 5.1 会话中运行：

Import-Module 某旧模块 -UseWindowsPowerShell

这种方式能让老模块在 7 的环境里“借壳”运行，代价是性能略低、跨会话传对象有序列化开销。三是如果模块实在无法迁移，就在需要时显式切回 5.1 执行那部分逻辑。

4.2 PSModulePath 的差异与统一

模块搜索路径PSModulePath在 5.1 和 7 里默认值不同。7 默认只包含自己的模块目录和用户级模块目录，不包含 5.1 的系统模块路径。这导致一些装在系统目录的模块在 7 里找不到。

查看当前值：

$env:PSModulePath -split ';'

如果你希望 7 也能访问 5.1 的某些模块目录，可以临时追加：

$env:PSModulePath += ';C:\Program Files\WindowsPowerShell\Modules'

但不建议把这个写死到 profile 里长期生效，因为把 5.1 的模块路径混进 7 可能引入兼容性问题。更干净的做法是把需要的模块单独安装到 7 的用户模块目录，用Install-Module指定-Scope CurrentUser，让它装到 7 自己的路径下。

4.3 脚本语法差异的快速自查

大部分基础语法在 5.1 和 7 之间是通用的，但有几类差异需要留意。一是某些 .NET 类型的方法签名变了，比如涉及加密、编码的部分；二是 7 新增的语法（如三元运算符? :、管道链运算符&&||）在 5.1 里不认，如果你写的脚本要两边都能跑，就别用这些新语法；三是Get-WmiObject在 7 里被移除，要换成Get-CimInstance。

自查的办法是拿你的核心脚本在 7 里跑一遍，看报错。对于Get-WmiObject这类明确被移除的命令，7 通常会给出替代建议。批量排查可以用：

Get-Command -Module Microsoft.PowerShell.Management | Where-Object { $_.Name -like '*Wmi*' }

确认你脚本里用到的命令在 7 里是否还存在。这个过程有点像搬家，东西一件件过一遍，该换的换，该扔的扔。

5. 常见问题速查与避坑经验

5.1 装了但打开还是 5.1 的排查路径

这是最高频的问题，按下面的顺序排查基本能定位：

排查时有个通用技巧：在出问题的终端里执行$PSVersionTable.PSVersion，看主版本号是 5 还是 7，再执行(Get-Process -Id $PID).Path看实际加载的可执行文件路径。这两个信息一出来，问题基本就清楚了。

5.2 中文乱码与编码问题

7 在编码处理上比 5.1 现代很多，默认输出编码是 UTF-8，这本来是好事，但在一些老环境里反而会导致中文显示乱码，因为老的控制台代码页可能是 GBK。

如果遇到输出中文乱码，先看当前编码：

[Console]::OutputEncoding

如果需要在特定场景下临时切回兼容编码：

[Console]::OutputEncoding = [System.Text.Encoding]::GetEncoding('GBK')

但更好的做法是让整个链路统一到 UTF-8。在 profile 里设置：

$OutputEncoding = [System.Text.UTF8Encoding]::new() [Console]::OutputEncoding = [System.Text.UTF8Encoding]::new()

这样新开的 7 会话默认就是 UTF-8，配合现代终端一般不会再有乱码。老脚本里如果有硬编码 GBK 的地方，需要单独处理。

5.3 性能相关的几个实测观察

升级到 7 之后，最直观的感受是启动速度和管道处理速度。7 的启动通常比 5.1 快一些，尤其是冷启动。管道处理方面，ForEach-Object -Parallel是 7 的杀手锏，处理大量对象的并行操作时提升明显。

但并行不是无脑开。-Parallel参数配合-ThrottleLimit控制并发数，默认是 5。并发开太大反而会因为线程调度和资源竞争拖慢速度，尤其是操作涉及磁盘 IO 或网络请求时。我的经验是：CPU 密集型任务并发数设为逻辑核心数左右，IO 密集型任务适当降低，实测调优比理论值更靠谱。

1..100 | ForEach-Object -Parallel { # 你的处理逻辑 Start-Sleep -Milliseconds 100 } -ThrottleLimit 8

还有一点，并行块里的变量作用域和普通管道不同，外部变量需要用$using:前缀传入，这个坑第一次用基本都会踩。

5.4 卸载与回退的注意事项

万一升级后遇到无法解决的问题需要回退，winget 安装的可以用：

winget uninstall --id Microsoft.PowerShell

MSI 安装的走控制面板卸载。ZIP 包直接删目录、清理 PATH 即可。卸载 7 不会影响系统自带的 5.1，这也是共存方案的好处——回退成本很低。

但要注意，卸载前把你迁移到 7 的 profile 里的自定义内容备份出来，否则重装后又要重新配一遍。我习惯把 profile 内容纳入版本管理，或者至少定期复制一份到云盘，这种小习惯在关键时刻能省不少事。

6. 我个人的几条实操体会

折腾环境这件事，最怕的是“看起来装好了但用起来处处别扭”。我的经验是，装完 7 之后别急着把 5.1 抛到脑后，先并行用一两周，把日常脚本在 7 里跑一遍，遇到问题记录下来逐个解决。这个过渡期能帮你发现很多隐藏的兼容性问题，而不是等到某个关键任务执行时才暴雷。

另外，PATH 和执行策略这两件事，改之前先记下原值，改完立刻验证，出问题能快速还原。环境变量这种东西，改错了排查起来很费时间，养成“改前备份、改后验证”的习惯比什么都强。

最后分享一个小技巧：在 7 的 profile 里加一个快速查看版本和路径的函数，每次开终端顺手确认一下环境对不对，比事后排查省心得多。

function Get-PwshInfo { [PSCustomObject]@{ Version = $PSVersionTable.PSVersion.ToString() Edition = $PSVersionTable.PSEdition ExePath = (Get-Process -Id $PID).Path } }

环境配置这种事，一次做扎实，后面几年都省心。上面这套流程我在多台机器上重复验证过，winget 路线最顺，ZIP 路线最可控，按自己的环境选一条走通就行。