PowerShell运维实战指南：从CMD差异到执行策略与故障恢复-代码聚汇网

PowerShell运维实战指南：从CMD差异到执行策略与故障恢复

FFFire小火·2026-08-29·阅读 22 GEO检测（免费）

PowerShellCMD执行策略

|难度：普通|阅读约 42 分钟

干运维这些年，我几乎每天都在跟 PowerShell 打交道。不管是给云主机批量下发配置、写脚本定时巡检，还是处理各种“看着就慌”的系统故障，PowerShell 都是绕不开的第一工具，我手里的 Windows 云服务器基本全靠它续命。很多朋友私信问我：PowerShell 到底怎么学、怎么用、报错了怎么办？尤其是网上那些热搜问题——exe 全打不开、cmd 和任务管理器全废了、执行策略拦截了命令、Windows 7 装高版本 PowerShell 装不上……我这篇就把这些年踩过的坑和验证过的处理思路一次性整理出来，不灌水，直接给能落地的操作。

如果你是刚入门的纯新手，可以从头看；如果你已经是老手，直接跳到卡住你的那部分。我尽量用大白话讲原理，用真实命令讲操作，让每个看完的人都能自己上手排一遍。

1. 先搞明白你手里这个黑窗口是什么：PowerShell和CMD的底层区别

1.1 为什么总有人把PowerShell当成CMD的升级版

这个误解太常见了。很多人打开 PowerShell，发现界面长得跟 CMD 差不多，敲 dir 也能出文件列表，就下意识觉得“这不就是高级版 CMD 吗”。实际上，这俩东西底层设计完全不是一个思路。

CMD 可以理解成一台老式电话交换机，能做的操作就是预先定义好的那几件事：切换目录、复制文件、运行程序。它跟系统之间的沟通方式是“文本管道”——上一个命令输出的文本，下一个命令拿到后还得做字符串解析，非常费劲，而且一旦文本格式变化，结果就可能出错。

PowerShell 则像一套完整的自动化控制台。它跑在 .NET 框架的托管环境上，命令输入输出不是“文本”，而是“对象”。什么意思？你敲 Get-Process 拿到的不是几行字，而是一个个进程对象，每个对象自带属性：进程名、PID、内存占用、CPU 时间等等。你可以直接把这些对象丢给 Sort-Object、Where-Object、Export-Csv 去处理，整个过程不会因为“显示格式变了”而出错。

这个差异是理解 PowerShell 一切高级用法的钥匙。很多人学了半天觉得“PowerShell 太绕”，就是因为还在拿 CMD 的思维去套它。

1.2 对象管道 vs 文本管道：这是两个时代的产物

我用一个实际例子说明对象管道的威力。

在 CMD 里，想找出内存占用最高的 5 个进程，你得靠 tasklist 输出文本，再拿 findstr 过滤，有时候还得配 for /f 循环做字符串切分，写出来的命令又长又脆，换一个系统语言环境就可能失效。

在 PowerShell 里只需要这么一行：

powershell复制Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 5

这行命令非常直白：获取所有进程对象，按工作集内存倒序排序，取前 5 个。每步操作的对象是结构化的，不用关心系统显示语言是中文还是英文，结果字段永远稳定。这就是现代 Windows 从服务器到云主机初始化配置都默认走 PowerShell 的核心原因——它不是“能跑命令”，而是“可编程的系统管理平台”。

再举个例子。你需要在 100 台主机上批量检查某个服务是否在运行，CMD 里写这个脚本会非常痛苦，要处理输出编码、字段切分、错误判断。PowerShell 里直接：

powershell复制$servers = Get-Content C:\servers.txt
$servers | ForEach-Object {
    Get-Service -ComputerName $_ -Name "MyService" -ErrorAction SilentlyContinue |
        Select-Object MachineName, Status, Name
} | Export-Csv C:\result.csv -NoTypeInformation

三行搞定一个批量巡检任务，这就是“对象管道”在现代运维里不可替代的价值。

1.3 什么时候该用PowerShell，什么时候该老老实实用CMD

不是所有场景都需要 PowerShell。我自己的习惯是分情况：

只是快速 ping 一个 IP、打开文件管理器、跑一个第三方命令行程序，CMD 更轻量，启动快，操作顺手。
需要写脚本、批处理、调用系统 API、处理 JSON/XML、设置计划任务、管理服务，直接 PowerShell，别犹豫。
如果是从 Linux 环境转过来的运维，PowerShell 上手会比 CMD 舒服得多，因为它的管道、变量、函数用法和 Bash 在思路上更有共通之处。

另外一个实用建议：在 CMD 里你可以直接输入 powershell 回车，切换到 PowerShell 环境。反过来，PowerShell 里输入 cmd 也会进入 CMD。两者互切，不需要反复开新窗口。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 版本清查与Windows 7困局：查版本、装高版本的正确姿势

2.1 一条命令看清当前PowerShell版本

管理 Windows 系统的第一步，永远是确认环境。我处理过太多“命令明明存在却报错”的案例，查到最后都是 PowerShell 版本太老，某个 cmdlet 在旧版本里根本不存在。

查看版本最直接的方式：

powershell复制$PSVersionTable.PSVersion

$PSVersionTable 是 PowerShell 内置的只读变量，保存了当前运行环境的关键版本信息。除了 PSVersion，你还能看到 CLRVersion（公共语言运行时版本）、PSCompatibleVersions（兼容版本列表）、WSManStackVersion 等字段。排查问题的时候，这些信息经常能帮你缩小范围。

我的习惯是上到任何一台新机器，第一件事就是敲这行命令。如果看到主版本号小于 5，很多新语法和模块都会有问题，得先考虑升级。

2.2 Windows 7装高版本PowerShell为什么这么折腾

虽然 Windows 7 已经是很老的系统了，但实际工作中还是能碰到，尤其是一些特殊设备或者存量业务环境。Windows 7 默认装的是 PowerShell 2.0，想升到 PowerShell 5.1 需要先装 WMF 5.1（Windows Management Framework 5.1）。

为什么折腾？因为 WMF 5.1 对前置条件要求很严：

必须是 Windows 7 SP1，不能是没打补丁的原始版；
需要先安装 Microsoft .NET Framework 4.5.2 或更高版本；
安装前必须关闭所有 PowerShell 会话、Windows Update 服务，因为某些组件文件会被锁定。

少了任何一个前置条件，安装程序要么直接报错，要么装完后启动时报“找不到文件”。我自己实测过的最稳顺序是：

先把系统补丁打到 Windows 7 SP1，重启；
安装 .NET Framework 4.5.2+，装完重启；
关闭所有占用 PowerShell 的程序，包括控制台、VS、Windows Update；
安装 WMF 5.1 安装包；
重启，再验证 $PSVersionTable.PSVersion。

这个顺序每一步都有作用，不能乱跳。

2.3 安装途中“找不到文件”的真实原因与处理

“Windows PowerShell 弹出找不到文件”这个问题出现的频率非常高，我在排查中总结出三个主要原因。

第一，安装包版本与系统版本不匹配。比如在 Windows 7 上装针对 Windows 8.1 的 PowerShell 版本，安装程序在解压阶段就会报错，因为内核模块对不上号。第二，系统上已有的 PowerShell 版本过新或过旧。WMF 安装包对“从哪个版本升到哪个版本”有明确的兼容矩阵，不支持乱跳。第三，文件权限被修改或者杀毒软件拦截。安装目录的 ACL 被改过，或者杀毒软件隔离了部分 DLL，就会在启动时提示找不到文件。

遇到这类问题，我建议先不要盲目重装，打开“事件查看器”看应用程序日志里的错误码，根据错误码去查具体原因。如果有系统还原点，就先还原到安装前的位置，再检查前置条件，把问题一步步排除。

2.4 装完以后的第一件事：把执行策略配好

高版本 PowerShell 装好后，如果不配置执行策略，你第一次跑脚本就会遇到那个著名的红色报错：“无法加载配置文件，因为在此系统上禁止运行脚本”。

这个问题不是 PowerShell 坏了，而是系统默认安全策略太严格。执行策略的深入说明我后面会用一整节来展开，这里先给一个相对安全的初始配置：

powershell复制Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

RemoteSigned 的含义是：本地创建的脚本可以直接运行，从网络下载的脚本必须带有可信发布者的数字签名。这个策略对大多数开发者和运维人员来说，够用又安全。加 -Scope CurrentUser 可以只影响当前用户，不动整个系统的默认配置，降低风险。

3. 全网最慌的场景：exe、cmd、任务管理器全打不开，怎么用PowerShell救人

3.1 这类故障是怎么发生的：先讲清楚机制

“所有 exe 文件都打不开，cmd 打不开，PowerShell 打不开，任务管理器也打不开，怎么救？”——这是运维群里隔三差五就会出现的问题。

这类故障的根源，大多数时候不是系统彻底坏了，而是文件关联被篡改。恶意软件或误操作把 .exe 文件关联改掉，系统不知道“双击 exe 该用哪个程序打开”，甚至把默认打开程序指向一个不存在的路径，结果所有 exe 全部无法启动，连带 cmd、PowerShell、任务管理器全部遭殃。

还有一种常见原因是注册表策略被写入。HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer 下面如果存在 DisallowRun 键，并且值非零，系统就会按列表禁用指定程序。很多恶意程序喜欢往这个位置写东西，用完也不清理，用户重启之后直接傻眼。

3.2 恢复操作的完整链路

遇到这种情况别慌，也别急着重装系统，按下面的顺序排查恢复。

第一步，按住 Shift 再点“重启”，进入 Windows 恢复环境（WinRE）。如果系统能进恢复环境，说明系统核心还在，大概率有救。

第二步，在恢复环境里选择“疑难解答”->“高级选项”->“命令提示符”。这个命令提示符是独立于主系统的，不受主系统文件关联问题的影响，是我们用来修系统的工具。

第三步，在命令提示符里检查并修复注册表。恢复环境里没有图形化的注册表编辑器，但可以用 reg.exe。

先看看是否存在问题键：

bat复制reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" /v DisallowRun

如果存在，删除：

bat复制reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" /v DisallowRun /f

再恢复 exe 文件关联：

bat复制assoc .exe=exefile
ftype exefile="%1" %*

assoc 命令的作用是把 .exe 扩展名重新关联到 exefile 类型，ftype 则定义 exefile 类型要怎么执行。两个都要做，只做其中一个可能恢复不完整。

第四步，重启系统，看是否恢复正常。如果主系统已经进不去桌面，还可以考虑把系统盘挂载到另一台机器上修复注册表，但对一般用户来说操作复杂度太高，优先用恢复环境。

如果你的系统还能打开 PowerShell，只是任务管理器被禁掉了，不需要进恢复环境，直接在管理员 PowerShell 里执行：

powershell复制Remove-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" -Name "DisallowRun" -ErrorAction SilentlyContinue

然后重启 explorer 进程：

powershell复制Stop-Process -Name explorer -Force
Start-Process explorer

任务管理器一般就能回来了。

3.3 一个操作前必须想清楚的判断点

修复之前，先冷静判断一件事：系统里有没有没保存的重要数据。恢复环境的操作可能会触发重启，如果用户正在编辑文档，数据可能丢失。

另一个判断点是：这个故障是不是装了某个第三方安全软件之后才出现的。如果是，修好之后要立刻卸载那个软件，否则下次重启可能又掉进同一个坑。

另外，系统恢复正常后，强烈建议立刻创建一个系统还原点。我维护了这么多年服务器，深深体会到还原点关键时刻能省多少事。Windows 的还原点不是万能，但面对这种系统级故障，它是成本最低的后悔药。

4. 开机自启脚本的几种正经写法，和那些坑

4.1 任务计划程序方式：最稳的一条路

云主机的运维中，设置开机自启是家常便饭。我首推“任务计划程序”方式，因为它可以指定触发条件、执行身份、延迟时间、失败重试策略，控制能力最强。

用 PowerShell 注册一个开机自启计划任务：

powershell复制$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-NoProfile -ExecutionPolicy Bypass -File C:\Scripts\startup.ps1"
$trigger = New-ScheduledTaskTrigger -AtStartup
$settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable
Register-ScheduledTask -TaskName "MyStartupScript" -Action $action -Trigger $trigger -Settings $settings -RunLevel Highest

这里有三个关键参数值得多说几句：

-RunLevel Highest 表示以管理员权限运行，很多初始化脚本需要管理员权限才能创建目录、修改注册表、安装服务；
-ExecutionPolicy Bypass 表示该任务运行脚本时绕过执行策略限制，因为计划任务里的 PowerShell 不会继承交互会话的设置；
-NoProfile 避免加载用户配置文件，减少不必要的依赖和报错。

如果是需要延迟启动，避免系统还没完全就绪脚本就开始跑，可以在注册触发器后单独设置延迟：

powershell复制$trigger.Delay = "PT30S"
Set-ScheduledTask -TaskName "MyStartupScript" -Trigger $trigger

PT30S 是 ISO 8601 时间间隔格式，表示延迟 30 秒。这个功能在做需要依赖网络的启动脚本时特别好用。

4.2 启动文件夹方式：简单但有局限

把脚本或脚本快捷方式放到启动文件夹，是最常见的用户级自启方式。路径有两个：

当前用户启动文件夹：%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup
所有用户启动文件夹：C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

当前用户路径不需要管理员权限，设置简单，适合普通软件的自启动。局限也很明显：没有错误重试、没有延迟设置、没法指定以管理员身份运行（UAC 会拦截），而且容易被安全软件重点关注。

在云环境里，我一般只用启动文件夹跑一些日志清理类的小脚本，核心服务的自启还是用任务计划程序或者注册成 Windows 服务。

4.3 注册表Run键方式：适合管理员精细控制

注册表 Run 键是 Windows 老牌自启动机制，常用位置有两个：

HKCU\Software\Microsoft\Windows\CurrentVersion\Run
HKLM\Software\Microsoft\Windows\CurrentVersion\Run

用 PowerShell 写入：

powershell复制Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run" -Name "MyScript" -Value "powershell.exe -NoProfile -ExecutionPolicy Bypass -File C:\Scripts\startup.ps1"

注册表方式的特点是启动时机比较早，而且能跨会话生效。但坑也明显：写入的路径如果写错，开机时会有弹窗报错，系统本身不会崩，但体验很差。另外 HKLM 下的 Run 键需要管理员权限，写之前确认当前会话是管理员。

我在使用注册表方式时习惯用一个技巧：把实际要运行的内容写到一个 .cmd 文件里，Run 键只指向那个 .cmd，而不是直接写一长串 PowerShell 参数。这样后续要调整脚本内容，不需要改注册表，直接替换文件内容就行，出问题回滚也方便。

4.4 自启脚本的常见翻车场景

自启脚本最容易翻车的几个点，我一个个说。

第一，路径问题。脚本里如果有相对路径，开机时的工作目录很可能不是脚本所在目录，导致找不到文件。解决办法是在脚本开头强制切换路径：

powershell复制Set-Location -Path $PSScriptRoot

$PSScriptRoot 是 PowerShell 3.0 以后内置的变量，表示脚本所在目录，非常可靠，比 Get-Location 或者相对路径都稳。

第二，网络依赖。很多云主机的自启脚本需要访问内部网络资源，但开机时网络可能还没就绪。要么加延迟，要么在脚本里做网络探测循环：

powershell复制$ready = $false
for ($i = 0; $i -lt 30; $i++) {
    if (Test-NetConnection -ComputerName "内部服务器IP" -Port 80 -InformationLevel Quiet) {
        $ready = $true
        break
    }
    Start-Sleep -Seconds 2
}
if (-not $ready) { Write-Warning "网络未就绪，跳过后续逻辑" }

这样就不会出现脚本跑了一半发现连不上数据库、白执行一堆操作的尴尬。

第三，日志缺失。自启脚本如果不写日志，出了问题你只能靠猜。我建议每个自启脚本开头都做一次日志初始化：

powershell复制Start-Transcript -Path "C:\Logs\startup_$(Get-Date -Format 'yyyyMMdd_HHmmss').log" -Append

Start-Transcript 会把后续所有输出记录到文件，排查问题的时候能省很多事。

5. 执行策略（Execution Policy）到底是什么：从“被拦截”到“完全控制”

5.1 四种策略等级

执行策略是 PowerShell 的安全机制，控制的是“PowerShell 能否运行脚本”，不是“能否执行命令”。很多新手一看到红色“禁止运行脚本”报错就慌，其实理解了策略等级，问题就很清晰。

常见的策略等级：

策略	含义	适用场景
Restricted	默认最严格，禁止任何脚本运行，只允许交互式命令	安全要求极高的公有环境
AllSigned	所有脚本必须经过数字签名	企业合规环境，有内部签名证书
RemoteSigned	本地脚本可运行，网络下载脚本必须签名	个人开发和一般运维，最常用
Unrestricted	所有脚本都可运行，网络脚本有安全警告	临时环境、教学演示
Bypass	完全不做拦截，也不警告	自动化部署、无交互场景

查看当前策略用：

powershell复制Get-ExecutionPolicy -List

这个命令列出当前用户、当前进程、本地机器等各作用域的策略值。看到 Undefined 表示该作用域没有显式设置，会继承默认策略。排查策略问题第一步永远是这个命令。

5.2 -ExecutionPolicy Bypass 和 -ep bypass 的用法与风险

很多下载脚本或安装操作，会看到这样的命令：

powershell复制powershell -ep bypass -c "irm https://example.com/install.ps1 | iex"

这段命令的作用是：以 Bypass 策略启动 PowerShell，下载一个远程脚本并立即执行。-ep 是 -ExecutionPolicy 的缩写，-c 是 -Command 的缩写。

这类命令在自动化安装场景里很方便，但风险极高。一旦下载的脚本被篡改，相当于直接把系统控制权交给远程脚本。我自己的原则是：只有在绝对信任脚本来源，并且确实需要脚本在无交互环境下执行时，才用 Bypass。更安全的做法是先把脚本下载到本地，审查完内容，再以 RemoteSigned 策略执行。

一个折中方案是：

powershell复制Invoke-WebRequest -Uri "https://example.com/install.ps1" -OutFile C:\temp\install.ps1
Get-Content C:\temp\install.ps1 -TotalCount 100
powershell -ExecutionPolicy RemoteSigned -File C:\temp\install.ps1

先下载、先看，再决定跑不跑，这个习惯能避免至少 80% 的脚本类安全事件。

5.3 当前环境策略拦截PowerShell读取命令的典型场景

“当前环境策略拦截了 PowerShell 读取命令”这个报错，是最近很多 AI 类工具（比如 Codex）集成 PowerShell 时常见的问题。原因很简单：这类工具要调用 PowerShell 来执行自动化命令，但当前环境执行策略默认过严，导致工具无法读取或执行命令。

解决方案分两步。第一步，确认当前策略：

powershell复制Get-ExecutionPolicy -List

第二步，按需为当前用户放宽策略：

powershell复制Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

如果只是临时想让当前进程允许执行，不改系统设置，可以启动 PowerShell 时加上 -ExecutionPolicy Bypass。但这种方式仅对当次命令行生效，关掉窗口就失效，适合临时测试。

5.4 什么情况下“绕过”是合理的

不是所有 Bypass 都危险。很多自动化部署场景——CI/CD 流水线、云主机初始化脚本、无人值守任务——都需要脚本自动执行，不能停下来等人点“允许”。这时候使用 Bypass 是理性的选择，因为它本身就是为这种无交互场景设计的。

关键在于“是否可控”。脚本放在你完全掌控的存储库或镜像里，内容经过审查、版本有记录，Bypass 的风险就可控。如果脚本来源不明、内容不看就直接跑，那等于把安全责任全部外包给远程服务器，这是运维里最忌讳的事。

6. Codex环境下配置PowerShell 7的实战记录

6.1 Codex为什么需要PowerShell 7

Codex 是 OpenAI 推出的命令行工具，能在终端里直接让 AI 协助完成开发任务。它默认调用系统 shell 来执行命令。Windows 上如果只装了 Windows PowerShell 5.1，很多跨平台命令、新语法特性都跑不起来，所以配置 PowerShell 7 是 Codex 用户在 Windows 上的必修课。

PowerShell 7 和 Windows PowerShell 5.1 的区别很实在：

PowerShell 7 基于 .NET Core，跨平台支持 Windows/Linux/macOS；
支持三元运算符、管道链等新语法，写起来更顺手；
字符串处理和管道性能明显提升；
很多模块在 7 里内置，5.1 要单独装。

如果你只想用一个 PowerShell 版本解决所有问题，直接用 7 没毛病。但注意，很多老模块依赖 .NET Framework，在 PowerShell 7 里可能不兼容，所以实际环境中 5.1 和 7 往往会共存一段时间。

6.2 安装PowerShell 7的完整步骤

在 Windows 上安装 PowerShell 7 最省事的方式是用 winget：

powershell复制winget install --id Microsoft.PowerShell --source winget

如果 winget 版本太老或不可用，去 GitHub 上 PowerShell 官方 Releases 页面下载 .msi 安装包也行。安装时注意勾选“将 PowerShell 加入 PATH 环境变量”，否则后面在终端里敲 pwsh 会找不到命令。

安装完成后，验证版本：

powershell复制$PSVersionTable.PSVersion

显示 7.x 就说明装好了。Windows PowerShell 5.1 和 PowerShell 7 可以共存，系统里会出现两个不同的入口：Windows PowerShell 5.1 和 PowerShell 7（pwsh.exe）。

这里有个小坑：如果在 Windows PowerShell 5.1 里输 pwsh 提示找不到命令，多半是 PATH 没刷新。新开一个终端，或者手动刷新当前会话的环境变量：

powershell复制$env:Path = [System.Environment]::GetEnvironmentVariable("Path", "Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path", "User")

6.3 Codex当前环境策略拦截PowerShell读取命令的修复

Codex 在 Windows 上运行时如果报“当前环境策略拦截了 PowerShell 读取命令”，处理步骤我们前面分析了原理，这里直接给完整方案。

方式一：为当前用户设置 RemoteSigned：

powershell复制Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

设置完再跑 Codex，一般就不报策略拦截了。

方式二：如果还报错，检查是不是有组策略层面的策略覆盖。组策略设置的执行策略优先级高于用户级，会直接覆盖 Set-ExecutionPolicy 的效果。确认方法：

powershell复制Get-ExecutionPolicy -List

看到 MachinePolicy 或 UserPolicy 不是 Undefined，说明有组策略干预。这时候需要看组策略编辑器里“Windows PowerShell”下的“脚本执行策略”选项，或者联系系统管理员处理。

方式三：只是临时绕开，不改变全局配置，可以在当前终端设置进程级执行策略：

powershell复制Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process

这个只在当前窗口生效，关闭终端就恢复原状，适合应急测试。

6.4 把PowerShell 7设为默认终端的配置

Codex 在 Windows 上默认使用哪个 shell，取决于你终端的配置。想让它默认走 PowerShell 7，可以在 Windows Terminal 的设置里把默认配置文件改成 PowerShell。

如果你用 VS Code 的集成终端，可以在 settings.json 里指定：

json复制{
    "terminal.integrated.defaultProfile.windows": "PowerShell",
    "terminal.integrated.profiles.windows": {
        "PowerShell": {
            "path": "C:\\Program Files\\PowerShell\\7\\pwsh.exe"
        }
    }
}

还有一个更底层的方式是修改系统环境变量 ComSpec，但我不建议这样做。很多遗留批处理脚本依赖 cmd.exe 的行为，强行替换会引发不可预期的问题，性价比不高。

我在实际操作中的一个体会是：PowerShell 7 配好后，Codex 执行命令的整体体验明显更稳，尤其是处理 JSON、操作对象管道的任务，5.1 和 7 的差距非常明显。

再补充一个实用技巧：如果 Codex 执行命令时出现中文乱码，在 PowerShell 7 的 profile 里设置 UTF-8 输出：

powershell复制[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
$OutputEncoding = [System.Text.Encoding]::UTF8

这个技巧在处理中文输出和跨平台协作时特别实用，尤其是从 Linux 端连过来的开发环境，能省掉一堆编码相关的幺蛾子。

把上面这些内容整理完，我再分享一个自己用了很久的习惯：我会把常用函数和别名统一写进 $PROFILE，这样打开任何 PowerShell 窗口都能直接用。编辑 profile 的方法是：

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

然后往里加自己高频使用的命令封装，比如一个快速查系统状态的函数：

powershell复制function Show-QuickStatus {
    Get-Date
    Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion
    Get-PSDrive -PSProvider FileSystem | Select-Object Name, @{n='Free(GB)';e={[math]::Round($_.Free/1GB,2)}}
}

每次打开 PowerShell 敲一下 Show-QuickStatus，就能对当前机器有个快速认知，省去一堆重复命令。PowerShell 这东西，核心不是背命令，而是理解它的对象模型和执行策略机制。命令忘了能查，这两个核心认知建立了，你就能真的拿它干活，而不是被它折腾。