1. 为什么必须把 5.1 升级到 7.x：不只是版本号的变化
先说一下我自己的经历。去年我重装了一台 Windows 11 的工作机，系统装完、驱动装完、开发环境装完，结果打开终端一敲命令，发现 PowerShell 还停在 5.1。当时没太在意，直到我要跑一个用 Microsoft Graph 模块写的脚本，直接给我甩了一脸红色报错：“此模块需要 PowerShell 7.0 或更高版本”。这才意识到，Windows 自带的那套 5.1 在很多新场景下已经不够用了。
很多人在 Windows 11 上装完 PowerShell 7 之后，会发现自己面对的是两套 PowerShell 并存的局面：一个是系统自带的Windows PowerShell 5.1（你在开始菜单里搜“PowerShell”看到的那个），另一个是你手动装的PowerShell 7.x（命令是pwsh）。这并不是装错了，而是微软刻意做的设计——5.1 作为系统组件被深度集成到 Windows 的很多管理功能里，不能随便动；而 7.x 作为独立的应用更新迭代，两者可以共存。但这也带来一个问题：如果你不主动配置，系统很多地方默认调用的还是 5.1，你装了 7.x 也等于白装。
这篇指南我尽量写得实操一点，按照我自己从 5.1 迁移到 7.x 的完整流程来，覆盖升级前要检查什么、安装路径怎么选、装完之后的默认版本切换、执行策略配置、脚本兼容性处理，以及升级后最容易踩的几个坑。无论你是刚开始接触 PowerShell 的新手，还是已经用 5.1 写了不少脚本的老手，这篇文章应该都能给你一些参考。
先说 5.1 和 7.x 的核心区别。Windows PowerShell 5.1 是最后一个版本的 Windows PowerShell，它基于 .NET Framework，微软已经宣布它进入维护模式，只修安全漏洞不再加新功能。而 PowerShell 7.x 是基于 .NET（现代 .NET，跨平台）构建的，它的前身是 PowerShell Core 6，到 7.0 之后正式更名为 PowerShell。这不仅仅是底层框架换了，更重要的是带来了一批 5.1 里没有的新语法、新命令和性能优化。
举几个我在实际工作中感触最深的差异：
- ForEach-Object -Parallel可以并行处理集合，处理一万个文件的场景，5.1 里跑几分钟，7.x 里开 10 个并行任务十几秒就能跑完。
- 三元运算符（
condition ? value1 : value2）、空合并运算符（??）和空合并赋值运算符（??=），写简洁逻辑时特别好用。 &&和||命令链运算符，可以实现“前一个命令成功才执行后一个命令”的逻辑，这个热搜词里很多人问过版本支持问题，它就是 7.0 引入的。- 原生字符串（
@"..."@和@'...'@）的行为更符合直觉，转义处理更友好。 - 大量内置命令（比如
Invoke-RestMethod、ConvertFrom-Json）在性能和功能上做了增强，处理 JSON 数据时的默认行为也有变化。
还有一个更实际的理由：现在微软主推的很多模块，比如Microsoft Graph PowerShell SDK、Az（Azure）模块、Exchange Online Management V3，都明确要求 PowerShell 7 或更高版本。你继续用 5.1，就算能装上旧版模块，也拿不到新功能和 Bug 修复。所以从这个角度来说，升级到 7.x 不是“可选项”，而是“迟早要做的事”。
2. 升级前的三个前置检查：别装完就懵
在我给出安装步骤之前，强烈建议你先花两分钟做三个检查。很多人装完 PowerShell 7 之后一脸懵，报了各种莫名其妙的错，追根溯源都是因为跳过了这一步。
2.1 确认当前版本和系统版本
打开一个 PowerShell 窗口，执行：
$PSVersionTable输出结果里重点看两个字段：
PSVersion：当前 PowerShell 版本号，如果是5.1.x，说明你还在用 Windows PowerShell。PSEdition：值为Desktop表示是 Windows PowerShell（5.1），Core表示是 PowerShell 7.x。
顺便确认一下系统版本，按Win + R输入winver回车，确保你的 Windows 11 是 21H2 或更高版本。PowerShell 7.4 之后的版本要求 Windows 10/11 的 64 位系统，Windows 11 所有正式版都满足这个条件，所以系统这关一般没问题，但确认一下总没坏处。
2.2 检查执行策略
执行策略是 PowerShell 的一个安全机制，控制脚本能不能运行。很多人在安装完新版本后遇到“因为在此系统上禁止运行脚本”的报错，大概率就是执行策略没配置好。升级前先看一下当前状态：
Get-ExecutionPolicy -List输出会按作用域从低到高列出，一般你会看到：
Scope ExecutionPolicy ----- --------------- MachinePolicy Undefined UserPolicy Undefined Process Undefined CurrentUser Undefined LocalMachine Undefined如果全是Undefined，说明没有任何显式策略，Windows 会按默认规则处理——对于本地登录的用户，默认是Restricted，也就是禁止运行任何脚本。这对个人开发机来说太严格了，后面我会在配置部分详细讲怎么设置。
2.3 盘点存量模块和脚本
这一步是最容易被忽略但又最重要的。执行：
Get-Module -ListAvailable | Select-Object Name, Version, Path | Sort-Object Name把输出结果过一遍，重点看有没有你日常依赖的第三方模块，比如PnP.PowerShell、SqlServer、VMware.PowerCLI、Az等。为什么要在升级前做这个？因为 PowerShell 7 和 5.1 的模块加载路径是不同的。5.1 的第三方模块装在Documents\WindowsPowerShell\Modules或者C:\Program Files\WindowsPowerShell\Modules，而 7.x 默认查找的是Documents\PowerShell\Modules和C:\Program Files\PowerShell\Modules。你装完 7 之后如果发现某些命令找不到，多半就是因为模块路径不共享，这个在第 5 节我会详细说。
另外，快速扫描一下你磁盘上的.ps1脚本，看看有没有硬编码了powershell.exe来启动子进程的。这种脚本在 7 下面执行时仍会拉起 5.1，行为可能和你预期不一致。至少做到心里有数，回头迁移脚本时知道要改哪里。
3. 三条安装路径的实操与取舍：选最适合你的一条
PowerShell 7 在 Windows 11 上的官方安装方式主要有三种：命令行winget安装、GitHub Releases 下载 MSI 安装包、Microsoft Store 安装。我分别给你说清楚操作步骤和各自的特点。
3.1 winget 安装（推荐给大多数用户）
Windows 11 自带winget（Windows 包管理器），这应该是最省事的方式。打开一个普通 PowerShell 或终端窗口（不需要管理员权限，winget 会自动处理用户级安装），执行：
winget install --id Microsoft.PowerShell --source winget它会自动下载最新稳定版并安装。装完之后关掉当前终端窗口，重新打开一个，输入：
pwsh如果能进入 PowerShell 7 的交互界面（提示符显示版本号），说明安装成功。
用 winget 的好处是升级方便。以后要更新版本，直接执行：
winget upgrade Microsoft.PowerShell它会自动拉取新版本覆盖安装。对于不想记一堆下载地址、也不想整天去 GitHub 看版本的人来说，这条路径是首选。
需要注意的是，winget 安装的 PowerShell 7 默认是per-user 安装，也就是说只对当前登录用户生效。如果你这台机器有多个管理员账户，其他账户登录后可能是找不到pwsh命令的。多人共用电脑的场景，建议改用 MSI 安装并选择“为所有用户安装”。
3.2 MSI 安装包（推荐给需要精细控制的人）
如果你需要全机器安装、或者想安装在非默认目录、或者想要官方安装包的某些高级选项，去 GitHub Releases 页面下载 MSI 是最稳的。PowerShell 的官方仓库是PowerShell/PowerShell，在 Releases 页面找到最新的稳定版（比如 7.4.x 或 7.5.x），在 Assets 里找类似PowerShell-7.4.6-win-x64.msi的文件下载。
这里有个细节很多人会看错：文件名里的win-x64表示 64 位版本，win-x86是 32 位版本，win-arm64是 ARM 版。Windows 11 大多数电脑是 x64 架构，如果你的电脑是 ARM 芯片（比如一些骁龙处理器的 Windows 设备），就选win-arm64。不确定的话可以看任务管理器里的“CPU”信息，或者执行echo $env:PROCESSOR_ARCHITECTURE。
双击 MSI 文件进入安装向导后，会看到几个选项：
Add PowerShell to PATH environment variable：勾选后会把pwsh加进系统 PATH，这样在任何终端里都能直接敲pwsh启动。建议勾选。Register Windows Event Manifests：注册事件清单，让 PowerShell 的日志能写入 Windows 事件查看器。建议勾选。Enable PowerShell remoting：启用 WinRM 远程管理。如果你暂时不需要远程执行 PS 命令，可以不勾，后面需要时再用命令启用。Use Microsoft Update：开启后，PowerShell 会通过 Windows Update 通道接收更新。如果你希望版本保持最新，建议勾选。
MSI 安装还有一个隐藏参数可以在命令行下指定，比如用管理员权限执行：
msiexec.exe /i PowerShell-7.4.6-win-x64.msi ADD_PATH=1 REGISTER_MANIFEST=1 USE_MU=1 ENABLE_PSREMOTING=0 /qb/qb是静默安装加基础界面，适合在批处理里批量装多台机器时用。我个人在维护测试环境时就是这么装的，几台虚拟机一次性全部装好，省去挨个点向导的时间。
3.3 Microsoft Store 安装（推荐给追求自动更新的人）
在 Microsoft Store 里搜索“PowerShell”，找到由“Microsoft”发布的版本，直接点安装。这种方式本质上和 winget 类似，也是独立安装包，但会有个明显优势：通过 Store 安装的应用会自动更新，你基本不用管版本这件事。
不过 Store 安装也有一些局限：一是它同样是 per-user 安装，二是它不会自动添加右键菜单和 PATH（实际测试中 Store 版通常已经处理好了基础集成），三是部分高级 MSI 选项（比如加入 Windows Update）你没法控制。对于“只想用，不想折腾”的普通用户来说，这是最省心的选择，但对于要拿来做自动化运维、批量部署的工程师来说，还是 MSI 更可控。
3.4 三种方式怎么选
| 对比项 | winget | MSI 安装包 | Microsoft Store |
|---|---|---|---|
| 是否需管理员权限 | 不需要 | 全机器安装时需管理员 | 不需要 |
| 安装范围 | 当前用户 | 可全机器 | 当前用户 |
| 自动更新 | 手动执行 upgrade | 可选通过 Windows Update | 自动 |
| 高级选项（PATH、事件清单等） | 自动处理 | 完全可控 | 不可控 |
| 适合人群 | 大多数开发者、爱好者 | 运维、批量部署、特殊需求 | 普通用户 |
按我个人的建议：如果是自用开发机，winget 基本够用；如果是公司统一管理多台机器，MSI 加静默参数是正路；如果是帮不太懂电脑的朋友装，微软商店最省心。
这里还有一个常见疑问：装完 7 之后，原来开始菜单里搜索“PowerShell”出来的 Windows PowerShell 5.1 会消失吗？答案是不会。这两个版本默认是并存的，5.1 仍然保留，供系统组件和兼容旧脚本使用。这个设计初看会有点混乱，但看清楚下面这个区分就好：
powershell.exe→ Windows PowerShell 5.1pwsh.exe→ PowerShell 7.x
后面所有默认启动器的配置，其实是把“默认调用入口”从powershell.exe切成pwsh.exe，而不是删除 5.1。
4. 装完之后的核心配置：默认版本切换与执行策略
安装只是第一步，真正好用取决于装完之后的配置。我在这个环节踩过一次很典型的坑：装完 7 之后发现右键点“在终端中打开”，进去的还是 5.1，当时一度以为安装失败了。所以我把这个环节单独拉出来详细说。
4.1 让 Windows Terminal 默认启动 PowerShell 7
Windows 11 自带的终端应用叫 Windows Terminal，它可以通过下拉菜单切换配置文件。默认情况下它的配置文件列表里可能同时有“Windows PowerShell”和“PowerShell”两个选项，前者指向 5.1，后者指向 7.x。
打开 Windows Terminal，按Ctrl + ,打开设置界面：
- 左侧选择“启动”。
- 在“默认配置文件”下拉菜单中，选择“PowerShell”（注意不是“Windows PowerShell”）。
- 左侧选择“交互”或直接确认下面“默认终端应用程序”为“Windows Terminal”。
改完之后，新开的终端标签页默认就进入 PowerShell 7，提示符会显示类似PS C:\Users\你的用户名>，执行$PSVersionTable确认版本号是 7.x。
Windows Terminal 的配置文件本质上是 JSON 格式的，如果你更喜欢直接改配置，可以在设置界面左下角点“打开 JSON 文件”，把profiles.defaults的source字段指向 PowerShell 的 GUID。不过用界面操作更直观，一般不建议直接手改 JSON，除非你要批量同步配置。
4.2 右键菜单“在终端中打开”和 Win+X 菜单的处理
Windows 11 的右键菜单里有一个“在终端中打开”的选项，这个入口实际调用的是你在“默认终端应用程序”里设置的程序。如果你把默认终端设成了 Windows Terminal，那么右键打开后默认进入哪个 shell，就取决于 Windows Terminal 的“默认配置文件”设置。
所以这里有一个联动逻辑：右键“在终端中打开” → Windows Terminal → 默认配置文件选择“PowerShell”。这三步全部配好后，你几乎在所有场景下打开的 PowerShell 都是 7.x，除了某些特定的系统管理场景（比如按下Win + X选择“终端(管理员)”后可能会看到 5.1，这个后面讲兼容性时会解释）。
另外，如果你不想改变全局默认，只想在某些目录下快速用 7 打开，也可以直接在文件资源管理器地址栏输入pwsh，回车后就在当前目录启动了 7 的交互窗口。这个小技巧在日常操作中很实用。
4.3 执行策略的设置与作用域概念
装完 7 之后，第一次运行脚本时很多人会收到“因为在此系统上禁止运行脚本”的提示。原因我在第 2.2 节说过，默认执行策略是Restricted。解决办法是给当前用户设置一个合理的策略。
在 PowerShell 7 窗口里执行：
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser这里解释一下几个关键点，避免你稀里糊涂设置完又给自己挖坑：
RemoteSigned表示：本地创建的脚本可以运行，从互联网下载的脚本必须有可信数字签名才能运行。这是个人开发机最均衡的方案——既能跑自己写的脚本，又能防止无签名脚本直接执行。-Scope CurrentUser只影响当前用户，不需要管理员权限。如果你是机器的唯一用户，用这个作用域就够了。- 不要图省事设为
Unrestricted，它会在你运行下载的脚本时弹一堆警告；更不要设为Bypass，这等于完全关闭安全机制，除非你在做安全测试，否则不推荐。
设置完成后，用Get-ExecutionPolicy -List检查一下，确定CurrentUser那一列是RemoteSigned而不是Undefined。如果你之前已经被某个软件或教程设置过别的值，可能还需要处理一下作用域冲突，这个在第 6.1 节详细说。
执行策略还有一个容易让人困惑的点：Windows PowerShell 5.1 和 PowerShell 7 的CurrentUser作用域其实是各自独立存储的。你在 7 里设置完，打开 5.1 的窗口执行Get-ExecutionPolicy -List可能还是原来的值，所以如果两个版本都要用，两边都要设置一遍。不过说实话，你既然主要用 7，5.1 那边维持默认问题也不大，你写脚本时注意别在 5.1 里运行就行。
4.4 配置文件 $PROFILE 的迁移
每个 PowerShell 会话启动时都会加载一个配置文件，里面可以放你自己的别名、函数、自定义提示符、常用模块自动加载等。5.1 和 7 的配置文件路径是不同的，执行$PROFILE可以看到：
- 5.1：
C:\Users\<用户名>\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 - 7.x：
C:\Users\<用户名>\Documents\PowerShell\Microsoft.PowerShell_profile.ps1
如果你在 5.1 里积累了不少函数和别名，装完 7 之后不会自动生效，需要手动迁移。我的做法是这样的：
- 先执行
Test-Path $PROFILE检查有没有配置文件，如果没有就执行New-Item -ItemType File -Path $PROFILE -Force创建。 - 对比 5.1 的配置文件内容，把里面通用的部分（函数、别名、自定义 prompt、导入模块的语句）复制到 7 的配置文件里。
- 一些只对 5.1 有效的命令或模块路径要特别处理，比如用
if ($PSVersionTable.PSEdition -eq 'Core')做环境判断。
在迁移过程中，我建议你给新的配置文件分类组织，比如把函数放在一起、别名放在一起、启动时要导入的模块放在一起，加注释分隔。因为 PowerShell 7 的配置文件在$PROFILE加载时会执行一遍，如果你在里面写了一个 5.1 独有的模块导入语句，启动时会报错，虽然一般不致命，但每次开终端看到红字还是闹心。
4.5 环境变量和临时目录的差异（一个容易被忽略的坑）
还有一个很多人在升级后第一次跑脚本才发现的问题：$env:TEMP在 5.1 和 7 中指向的路径是不同的。
- 5.1 下，
$env:TEMP一般是C:\Users\<用户名>\AppData\Local\Temp\。 - 7.x 下，如果你通过某些方式以管理员权限运行，或者在某些服务会话里，
$env:TEMP可能是C:\Windows\System32\config\systemprofile\AppData\Local\Temp。
这意味着，如果你之前在 5.1 里写的脚本会在$env:TEMP创建一个临时文件并引用它，在 7 里跑的时候行为可能不一致，因为临时目录变了。解决方法是尽量不要依赖$env:TEMP的固定路径，而是用[System.IO.Path]::GetTempPath()来获取，这个 API 在两个版本下行为一致。或者，如果你确实要让脚本在两套环境里行为一致，可以在脚本开头显式设置：
$env:TEMP = "$env:LOCALAPPDATA\Temp" $env:TMP = $env:TEMP这个问题不算大，但遇到了会很困惑，因为报错信息往往不直观，所以在这里提前打个预防针。
5. 兼容性实测：模块、语法与脚本迁移的那些事
装完、配完之后，真正考验人的是现有脚本和模块的兼容性。我在迁移过程中做了不少实测，直接把结论和经验分享出来。
5.1 你的常用模块在 7 下面还能不能用
这个不能一概而论，我按模块类型分开说。
微软官方云服务模块：整体来看方向是明确支持 7 的。Microsoft.Graph、Az、ExchangeOnlineManagement等模块在 PowerShell 7 下都能正常工作，有些甚至只支持 7（旧版AzureAD模块虽然还能用，但官方已不再推荐，建议迁移到Microsoft.Graph）。需要注意的是，一些老版本模块安装包可能在 7 下加载时因为 .NET 版本不匹配而报错，通常升级到最新版就能解决。
本地管理模块：情况比较复杂。比如ActiveDirectory模块（Windows 下的 RSAT 组件版本），实际上它可以在 PowerShell 7 中加载（Windows 11 下有新版 AD 模块），但如果你用的是旧版 Windows 10 的 RSAT，可能不行。NetAdapter、DnsClient这类网络相关模块，在 Windows 11 上通常也能在 7 下用，因为它们本质上是调用系统 CIM/WMI 接口。但有个前提：需要先确认-Module导入时的报错信息，如果提示“无法加载”，大概率是二进制模块编译目标不是 .NET，这时要么找替代模块，要么通过 Windows PowerShell 兼容层运行。
遗留第三方模块：如果你之前依赖某个已经不维护的老模块，升级后可能要两手准备。我的建议是：先试着在 7 里Import-Module一下，如果报错，再看是不是有 Active Directory 相关的依赖、是不是用到了 .NET Framework 特有 API。实在无法兼容的，可以在脚本里通过显式调用powershell.exe -Command来运行只支持 5.1 的代码片段，相当于在 7 的外壳里调用一个 5.1 的子进程。这个做法虽然不够优雅，但能解决业务依赖问题。
5.2 语法差异：新语法很好用，但要先知道它们存在
如果你从 5.1 直接跳到 7，最大的惊喜就是那些新语法。前面提到过的&&、||、三元运算符、??空合并运算符，都是实打实提升效率的。下面是我常用的一段对比：
在 5.1 里，你要写“如果文件夹不存在则创建”，通常这么写：
if (-not (Test-Path $path)) { New-Item -ItemType Directory -Path $path | Out-Null }在 7 里可以写得更紧凑：
Test-Path $path ? $null : (New-Item -ItemType Directory -Path $path)ForEach-Object -Parallel也很值得一用。比如你要批量检查几百个 URL 是否可访问：
$urls | ForEach-Object -Parallel { try { $resp = Invoke-WebRequest -Uri $_ -Method Head -TimeoutSec 5 [PSCustomObject]@{ Url = $_; StatusCode = $resp.StatusCode } } catch { [PSCustomObject]@{ Url = $_; StatusCode = 'Error' } } } -ThrottleLimit 20注意-Parallel里的脚本块默认不能访问外部变量（需要$using:语法），这和某些语言里的并行编程概念很像。我第一次用的时候就因为直接引用了外部变量导致结果全是空的，后来加$using:前缀就正常了。
这些新语法是 7 的独有能力，但也意味着你的旧脚本如果在 5.1 环境下继续运行会遇到语法错误。所以涉及团队协作时，最好在脚本头部加一行声明：
#requires -version 7这样，即使在 5.1 里被误执行，也会立即报出版本不满足的错误，而不是跑到一半才爆出奇怪的语法解析问题。
5.3 内置命令的行为差异
有些命令虽然名字没变，但行为在 7 里做了调整，如果你没意识到，就会出现“脚本逻辑没变但结果不同”的诡异问题。举两个我实际遇到过的例子：
ConvertFrom-Json的-Depth默认值：在 5.1 里默认只有 2 层，JSON 嵌套超过两层就会被截断成字符串；在 7 里默认深度是 1024，基本不会再遇到嵌套深导致的数据丢失问题。反过来，如果你在 7 里写脚本，然后放到 5.1 里跑，就可能会因为深度问题失败。Invoke-RestMethod和Invoke-WebRequest的底层实现：7 版本用了现代 .NET 的 HTTP 栈，性能更好，但某些边界行为（比如对 HTTP 状态码的处理、对特定字符编码的判断）和 5.1 略有差异。如果你的脚本依赖某个特定 HTTP 错误码的捕获方式，建议在 7 下重新验证一遍。
还有Get-ChildItem在 7 里新增了-FollowSymlink参数；New-Item对软链接、硬链接的创建更完善了（New-Item -ItemType SymbolicLink在 7 里行为更稳定）；管道传递$?的含义在脚本块里也有了更细致的区分。这些变化提升体验的同时，也让 5.1 的老脚本在 7 里不能盲目运行，逐条验证是必须的。
5.4 脚本迁移的策略建议
面对存量脚本，我不建议一次性全部改写，因为风险大、收益也未必高。我的做法是按优先级分批推进：
- 基础设施类脚本（创建用户、拉取日志、批量处理文件等）优先迁移，这类脚本通常只用了基础命令和语法，迁移成本低。
- 依赖第三方模块的脚本，先确认模块最新版是否支持 7，支持就迁，不支持就保留在 5.1 环境，用计划任务或显式调用方式运行。
- 敏感业务脚本（比如生产环境变更、数据库操作），先在测试环境验证再切。
迁移时可以用一个小的辅助函数来保证三方模块在两套环境下都能正常加载：
function Import-WithFallback { param([string]$ModuleName) if (-not (Get-Module -ListAvailable -Name $ModuleName)) { Write-Warning "模块 $ModuleName 不存在，请先安装。" return } try { Import-Module $ModuleName -ErrorAction Stop } catch { Write-Warning "在 PowerShell $($PSVersionTable.PSVersion) 下导入 $ModuleName 失败：$_" } }这样一个函数可以放到配置文件里，兼容两个版本的模块导入逻辑，不会因为某台机器环境不同而爆错。
6. 升级后最容易踩的坑：我的踩坑实录与解法
最后这部分，我把升级过程中遇到的高频问题整理出来，按照“现象 - 原因 - 解法”的方式记录，方便你对照排查。这些问题不少是热词里反复出现的，说明大家都遇到过。
6.1 “已成功更新你的执行策略，但在更具体的作用域中定义的执行策略”到底啥意思
先给结论：这不是一个错误，而是 PowerShell 的提醒。它的意思是：你确实通过命令更新了某个作用域的策略，但当前生效的最终策略可能会受到更具体作用域的限制。
我用一个例子说明。你执行：
Set-ExecutionPolicy RemoteSigned -Scope LocalMachine弹出一行提示：已成功更新你的执行策略，但在更具体的作用域中定义的执行策略优先。随后你用Get-ExecutionPolicy查看，发现当前值不是RemoteSigned。
原因在于执行策略的优先级顺序是：
MachinePolicy > UserPolicy > Process > CurrentUser > LocalMachine如果你的CurrentUser作用域里已经有某个值（比如Undefined不算，但有值是算的），那LocalMachine作用域设了也不会改变最终结果，因为CurrentUser更具体。
遇到这种情况，正确做法是执行：
Get-ExecutionPolicy -List看一下每一列的值，然后决定要改哪个作用域。如果你想让所有策略统一，可以对每个作用域分别设置，或者直接把不需要的设成Undefined：
Set-ExecutionPolicy -ExecutionPolicy Undefined -Scope CurrentUser Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine之所以拉出来单独讲，是因为这个提示措辞很有迷惑性，我第一次看到以为设置失败了，折腾了很久才发现其实只是“设置了但被覆盖了”。新手朋友看到它别慌，顺着作用域列表查一遍就能定位。
6.2 旧模块在 7 里找不到或加载失败
现象：你在 5.1 里明明安装了某个模块，比如Import-Module MyModule一直好用，到了 7 里却提示“找不到模块”。
原因前面提过，两个版本的模块搜索路径并不完全一致。区别在于：
- 5.1 默认路径：
C:\Program Files\WindowsPowerShell\Modules和C:\Users\<用户名>\Documents\WindowsPowerShell\Modules - 7 默认路径：
C:\Program Files\PowerShell\Modules和C:\Users\<用户名>\Documents\PowerShell\Modules
如果你的模块当初是Install-Module安装的，7 在多数情况下会自动从合适的源重新安装；但如果是手动拷进目录的，或者用过时的Save-Module装到了 5.1 专属路径，那就需要手动迁移。
最快的检查方法是执行：
$env:PSModulePath -split ';'看看当前环境到底搜哪些目录。如果确认模块确实只在 5.1 目录里，你有两种选择：把模块文件夹复制到 7 对应的目录；或者在 7 的$PROFILE里加一行：
$env:PSModulePath = "$env:USERPROFILE\Documents\WindowsPowerShell\Modules" + ';' + $env:PSModulePath不过这种做法我一般不建议长期用，因为 5.1 模块和 7 模块混在一起，容易导致同一模块存在两个版本、加载顺序混乱的问题。最好还是重新用Install-Module -Scope CurrentUser在 7 里装一遍，让它自动放到 7 的路径下。
6.3 某些工具明明装好了，但右键打开的还是 5.1
这个现象通常发生在你没有正确设置默认终端或默认配置文件的情况下。Windows 11 的很多入口（比如 Win+X 菜单里的“终端(管理员)”）调用的到底是谁，取决于两个设置：
- “设置” → “隐私和安全性” → “对于开发人员” → “终端”，确保“终端应用程序”是“Windows Terminal”。
- Windows Terminal 的“默认配置文件”必须选“PowerShell”。
如果都设了还是 5.1，你可以在 Windows Terminal 的标签页下拉菜单里手动选择“PowerShell”配置文件，然后右键标签页设置为默认。注意区分“默认终端应用程序”和“默认配置文件”，前者决定谁来托管终端界面，后者决定默认启动哪个 shell。
还有一个常见原因：某些软件安装时会在自己的配置里硬编码使用powershell.exe，比如部分 IDE 的集成终端、某些远程管理工具。这种情况下你改系统设置是没用的，需要在软件设置里手动指定 shell 为pwsh.exe。例如 VS Code，按Ctrl + Shift + P，输入“Terminal: Select Default Profile”，选择“PowerShell”（对应 7）即可。
6.4 原生命令的 stderr 处理差异：2>$null的奇怪行为
这个坑比较隐蔽，但遇到的人不少。在 5.1 里，如果你运行一个原生程序（比如git、curl.exe）并把 stderr 重定向到$null，基本都会正常忽略错误输出。但在 7 里，PowerShell 引入了新的$PSNativeCommandUseErrorActionPreference和更严格的stderr数据流处理逻辑。具体表现是：如果你设置了$ErrorActionPreference = 'Stop'，某些原生命令往 stderr 写信息（甚至不是错误）时，PowerShell 7 也会把它当成错误抛出来。
这在 5.1 中是不会发生的，因为 5.1 里 stderr 默认不会被当作 throw 的触发条件。所以你的脚本如果是从 5.1 迁移过来的，需要留意以下现象：
$ErrorActionPreference = 'Stop' git status 2>$null # 在 7 里可能触发 NativeCommandError解决方式有三种：
- 把
$PSNativeCommandUseErrorActionPreference设置为$false（PowerShell 7.3 及以后版本支持），恢复 5.1 的旧行为。 - 用
cmd /c包裹来运行原生命令，让它完全脱离 PowerShell 的 stderr 处理逻辑。 - 不用
$ErrorActionPreference = 'Stop'作为全局设置，改为对 cmdlet 单独加-ErrorAction Stop。
我的习惯是：如果是迁移脚本，直接把第三点作为默认方案——尽量少在全局设置$ErrorActionPreference，因为它的行为在不同版本之间真的有不小差异。
6.5 依赖 5.1 场景下的兼容方案：显式调用 powershell.exe
升级到 7 不代表你要和 5.1 彻底告别。某些场景下你仍然需要显式调用 5.1，最常见的就是那些只兼容 .NET Framework 的旧模块或旧脚本。比如某些古老的 SQL Server 模块版本、某些内网自研工具，它们的二进制程序集是按 .NET Framework 编译的，在 7（基于 .NET）下根本无法加载。
这时候我推荐的做法不是硬刚，而是封装一层转发函数。举个例子，假设你有一个旧脚本legacy.ps1，它只能在 5.1 里运行：
function Invoke-LegacyScript { param([string]$ScriptPath) powershell.exe -NoProfile -ExecutionPolicy Bypass -File $ScriptPath }然后在 7 里正常调用Invoke-LegacyScript -ScriptPath "C:\scripts\legacy.ps1"就行。这样既保持了 7 作为主力 shell 的地位，又不影响旧脚本的日常使用。注意-NoProfile参数很有用，它避免旧脚本在启动时加载 5.1 的配置文件，降低环境干扰。
反过来，如果你需要让 5.1 调用 7 的某个脚本，可以用pwsh.exe -NoProfile -File来调用。掌握了这个互调逻辑，两套环境就能和平共处。
写在最后：我的几个实操心得
整个过程走下来，我的体会是：升级到 PowerShell 7 并不难，难的是把整个工作流和配置一起迁移过来。如果你现在还在 5.1 上，我的建议是不要抱着“能用就行”的心态拖太久，越晚迁移，存量脚本越多，迁移成本越高。反过来，如果你已经升到了 7，前面说的这些配置和坑点，基本上就是接下来几天你会遇到的核心问题了。
最后再分享一个小技巧：我习惯在 PowerShell 7 的配置文件里加一行自定义提示符，通过修改prompt函数来显示当前是否处于管理员模式。因为升级后你会经常同时打开管理员和非管理员窗口，又都是 7 的界面，单靠标题栏区分很容易看岔，一个简单的红色提示就能避免很多误操作。这个思路和你迁移脚本一样——先给自己营造一个舒服可控的环境，再逐步把所有工作流搬过来，整套体系自然就稳定了。
