PowerShell开发环境搭建与优化：5.1、7.x、PATH、Profile及UTF-8配置

PowerShell开发环境搭建与优化：5.1、7.x、PATH、Profile及UTF-8配置

在上一篇文章中，我们比较了 CMD、PowerShell 和 WSL2 的区别，并建议 Windows 原生开发优先使用 PowerShell 7，同时保留 Windows PowerShell 5.1 处理兼容性问题。

但安装 PowerShell 7 之后，开发环境不一定就能正常工作。

例如：

• 已经安装 PowerShell 7，但输入 pwsh 提示找不到命令。
• Windows PowerShell 5.1 可以运行的脚本，在 PowerShell 7 中出现异常。
• 安装了 Node.js、Git 或 Codex，却提示命令无法识别。
• npm –version 提示 npm.ps1 无法执行。
• PowerShell 终端可以显示中文，输出到文件却出现乱码。
• 修改了环境变量，重新执行命令仍然无效。
• 配置了 $PROFILE，但 VS Code 和 Windows Terminal 中表现不同。

这些问题看起来互不相关，实际上都与 PowerShell 的运行环境有关。

本文不追求复杂的终端美化，而是从开发者日常使用出发，搭建一套稳定、可维护的 Windows PowerShell 环境。

最终希望实现以下目标：

• Windows PowerShell 5.1 与 PowerShell 7 正常共存；
• Windows Terminal 能够快速切换不同终端；
• Git、Node.js、Python 和 Codex 等工具可以被正确识别；
• PATH 与环境变量管理清晰；
• Profile 简单、安全、容易维护；
• 中文输出与 UTF-8 文件处理正确；
• 出现问题时能够快速定位原因。

本文适用于 Windows 10/11，重点介绍 Windows 原生环境。企业管理设备应优先遵循组织的软件安装和安全策略。

一、先理解PowerShell 5.1与PowerShell 7的区别

Windows 中可能同时存在两个 PowerShell。

一个是传统的 Windows PowerShell 5.1，另一个是现代 PowerShell 7.x。

它们名称相似，但并不是简单的版本升级关系。

1.1 主要区别

PowerShell 7 并不会直接覆盖 Windows PowerShell 5.1。

两者有独立的程序入口和安装位置，可以同时存在。

因此，推荐的策略不是卸载 PowerShell 5.1，而是：

让 PowerShell 7 成为日常默认环境，需要兼容旧模块时再使用 Windows PowerShell 5.1。

1.2 查看当前PowerShell版本

打开 PowerShell，执行：

$PSVersionTable

也可以只显示关键字段：

$PSVersionTable |
Select-Object PSVersion, PSEdition, OS

通常：

• Windows PowerShell 5.1 的 PSEdition 为 Desktop。
• PowerShell 7 的 PSEdition 为 Core。

注意，Windows PowerShell 5.1 中的 $PSVersionTable 可能没有 OS 属性，这并不代表命令执行失败。

1.3 检查两个PowerShell是否存在

Get-Command powershell.exe, pwsh.exe `
–ErrorAction SilentlyContinue |
Select-Object Name, Source

如果只找到 powershell.exe，可能说明 PowerShell 7 尚未安装，或者没有加入当前 PATH。

如果两个命令都存在，说明至少可以从当前环境定位到对应的命令入口。

还可以分别启动：

powershell.exe

以及：

pwsh.exe

这两条命令会进入对应的 PowerShell 环境，退出子 Shell 可以执行：

exit

二、安装PowerShell 7并与5.1共存

2.1 推荐使用WinGet安装

对于支持 WinGet 的 Windows 10/11 客户端，可以先检查：

winget —version

查询 PowerShell：

winget search —id Microsoft.PowerShell —exact

安装稳定版：

winget install —id Microsoft.PowerShell —source winget

WinGet 可能要求接受软件源或安装协议，并根据安装方式请求管理员权限。

需要注意，微软从 PowerShell 7.6 对应的 WinGet 安装包开始，默认安装方式有所调整，可能采用 MSIX。

因此，不应假定所有 PowerShell 7 安装都具有完全相同的文件目录。

如果企业环境明确要求 MSI 安装，应参考当前官方安装文档，选择相应的安装方式和适用版本。

2.2 验证安装

安装完成后，关闭并重新打开 Windows Terminal 或 PowerShell 窗口。

执行：

pwsh.exe —version

如果能够返回版本号，就说明当前环境可以找到并启动 PowerShell 7。

进一步检查：

pwsh.exe –NoProfile –Command '$PSVersionTable.PSVersion.ToString()'

这里的 -NoProfile 表示启动时不加载用户 Profile。

这个参数后续排查 PowerShell 启动异常时非常有用。

2.3 更新PowerShell 7

如果使用 WinGet 安装并管理 PowerShell，可以检查：

winget list —id Microsoft.PowerShell

并尝试：

winget upgrade —id Microsoft.PowerShell —source winget

实际能否通过 WinGet 升级，取决于安装来源、包类型和当前版本。

如果通过 MSI、MSIX 或 ZIP 手动部署，应采用与当前安装方式相匹配的更新流程。

不要直接删除 PowerShell 的安装目录来进行升级。

2.4 Windows Terminal应该如何配置？

推荐打开：

Windows Terminal → 设置 → 启动 → 默认配置文件

将默认配置文件设为 PowerShell 7。

另外保留：

• Windows PowerShell 5.1；
• 命令提示符（CMD）；
• 已安装的 WSL 发行版（如果需要）。

这样在一个 Windows Terminal 窗口中，就可以通过标签页切换不同环境。

需要强调：

Windows Terminal 是终端应用，PowerShell 才是实际执行命令的 Shell。

改变 Windows Terminal 默认配置文件，不等于卸载或者替换其他 Shell。

三、理解PATH：为什么安装了软件却提示命令不存在？

这是 Windows 开发环境中最常见的问题之一。

例如：

codex : 无法将“codex”项识别为 cmdlet、
函数、脚本文件或可运行程序的名称。

或者：

node : 无法将“node”项识别为…

出现这类错误，首先应检查命令是否存在，以及当前 Shell 是否能够定位到它。

3.1 PATH是什么？

PATH 是环境变量，包含一组用于搜索可执行程序的目录。

例如：

C:\\Windows\\System32
C:\\Program Files\\Git\\cmd
D:\\DevTools\\nodejs

当输入：

git —version

PowerShell 会按照命令解析规则，查找是否存在对应的别名、函数、Cmdlet、脚本或可执行文件。

对于外部程序，PATH 是重要的查找来源。

但是，PATH 不是唯一的命令解析机制。

PowerShell 中还存在函数、别名和 Cmdlet，因此不能仅靠查看 PATH 判断最终执行了哪个命令。

3.2 查看PATH

$env:PATH

如果只想逐行查看各目录：

$env:PATH –split ';'

Windows 中 PATH 项通常使用分号分隔。

建议优先观察目录是否存在、是否重复，以及是否包含已经卸载的软件路径。

3.3 检查命令到底来自哪里

例如：

Get-Command node –All

或者：

Get-Command git –All

也可以使用：

where.exe node

where.exe git

需要注意：

在 PowerShell 中，where 可能被解析为 Where-Object 的别名。

因此，要调用 Windows 的 where 程序，应该明确使用：

where.exe

Get-Command -All 与 where.exe 可以结合使用，前者能够显示 PowerShell 的命令解析结果，后者主要用于检查外部可执行程序入口。

3.4 理解环境变量的三个作用域

查看当前进程 PATH：

$env:PATH

查看用户级 PATH：

[Environment]::GetEnvironmentVariable(
"Path",
"User"
)

查看系统级 PATH：

[Environment]::GetEnvironmentVariable(
"Path",
"Machine"
)

需要注意，当前进程的 PATH 通常结合了不同来源，还可能被终端、IDE 或启动脚本进一步修改。

因此：

Process PATH 不一定等于 User PATH 与 Machine PATH 的简单字符串拼接结果。

3.5 临时添加工具目录

假设某个开发工具安装在：

D:\\DevTools\\bin

先确认目录存在：

Test-Path –LiteralPath "D:\\DevTools\\bin" –PathType Container

如果存在，可以在当前 PowerShell 会话临时增加：

$toolDir = "D:\\DevTools\\bin"

$paths = @($env:PATH –split ';' | Where-Object { $_ })

if ($paths -notcontains $toolDir) {
$env:PATH = "$toolDir;$env:PATH"
}

这里使用的是进程级环境变量。

关闭当前 PowerShell 会话后，这个临时修改不会自动成为永久配置。

这样做适合验证：

某个程序是否因为 PATH 缺少安装目录而无法启动。

3.6 如何永久修改PATH？

对于普通开发电脑，推荐通过 Windows 环境变量编辑界面操作。

进入：

系统属性 → 高级 → 环境变量

优先修改当前用户的 Path，而不是直接修改系统级 PATH。

将实际存在的工具目录添加为新条目即可。

修改完成后，重新启动相关终端和 IDE。

例如，VS Code 在环境变量修改前已经启动，其内部终端可能仍然继承旧环境。

这里不建议使用简单的字符串替换命令直接覆盖整个 PATH。

尤其不应把当前进程的 $env:PATH 原样写回用户级 PATH，因为其中可能已经包含系统级路径和临时路径。

四、Profile：让PowerShell拥有自己的开发配置

PowerShell 每次启动时，都可以根据配置加载相应的 Profile 脚本。

可以把 Profile 理解为：

PowerShell 会话启动时执行的个性化初始化脚本。

常见用途包括：

• 设置常用别名；
• 定义快捷函数；
• 配置提示符；
• 调整交互体验；
• 加载确实需要的模块。

但不建议把所有环境初始化操作都放进 Profile。

Profile 内容越复杂，越可能增加终端启动时间或产生环境差异。

4.1 查看Profile位置

$PROFILE

可以看到当前用户、当前宿主的 Profile 路径。

进一步：

$PROFILE | Select-Object *

通常可以看到四种配置范围：

PowerShell 5.1 与 PowerShell 7 通常使用不同的用户 Profile 目录。

典型默认路径如下：

Windows PowerShell 5.1：

Documents\\WindowsPowerShell\\Microsoft.PowerShell_profile.ps1

PowerShell 7：

Documents\\PowerShell\\Microsoft.PowerShell_profile.ps1

如果 Windows 的“文档”文件夹经过 OneDrive 或企业策略重定向，实际路径可能不同。

因此应以当前会话的 $PROFILE 为准，而不是在脚本中直接写死上述目录。

4.2 创建Profile

先确认：

Test-Path –LiteralPath $PROFILE

如果不存在：

$profileFile = $PROFILE.CurrentUserCurrentHost

if (-not (Test-Path –LiteralPath $profileFile)) {
$profileDir = Split-Path –Parent $profileFile

New-Item –ItemType Directory –Path $profileDir –Force |
Out-Null

New-Item –ItemType File –Path $profileFile |
Out-Null
}

如果已经存在，不要直接覆盖，应该先检查并备份原内容。

使用记事本打开：

notepad.exe $PROFILE

4.3 一个简单实用的Profile示例

建议初期只保留少量常用功能。

例如：

# PowerShell profile

# List directory contents
Set-Alias –Name ll –Value Get-ChildItem

# Jump to the local projects directory
function cproj {
$dir = Join-Path $HOME "Projects"

if (Test-Path –LiteralPath $dir –PathType Container) {
Set-Location –LiteralPath $dir
}
else {
Write-Warning "Projects directory not found: $dir"
}
}

保存后，打开新的 PowerShell 会话。

执行：

ll

可调用 Get-ChildItem。

执行：

cproj

可以尝试进入用户主目录下的 Projects 文件夹。

如果该目录不存在，会显示提示，不会自动创建目录。

注意：这里使用英文注释，是为了让同一份示例也容易被 Windows PowerShell 5.1 正确解析。

如果 Profile 包含中文字符串或其他非 ASCII 字符，还需要考虑后面介绍的脚本源文件编码问题。

4.4 Profile修改后为什么没有生效？

原因通常包括：

• 修改了另一个 PowerShell 版本的 Profile；
• 修改了另一个宿主的 Profile；
• 当前会话尚未重新加载；
• Profile 本身出现语法错误；
• 有效执行策略阻止 Profile 加载。

在受信任的配置文件上，可以手动重新加载：

. $PROFILE

这里的点号和后面的空格，是 PowerShell 的 Dot Sourcing 语法。

注意，这种方式会重新执行 Profile 中的全部代码。

如果 Profile 中有重复注册事件、修改 PATH 或启动程序等操作，反复加载可能造成副作用。

最简单的验证方式仍然是关闭当前窗口，然后打开一个新的 PowerShell 会话。

4.5 Profile配置错误导致PowerShell无法正常启动

可以先不加载 Profile 启动 PowerShell 7：

pwsh.exe –NoProfile

对于 Windows PowerShell 5.1：

powershell.exe –NoProfile

如果 -NoProfile 可以正常启动，但普通启动存在问题，就应该重点检查 Profile 内容。

但也不能因此排除模块、终端宿主或其他配置问题。

建议把 Profile 作为用户交互配置，而不是完整的项目运行环境依赖。

项目真正需要的环境变量、依赖版本和启动参数，最好通过项目自身的配置和脚本管理。

五、UTF-8编码：为什么终端正常，写入文件却乱码？

这是 Windows PowerShell 5.1 与 PowerShell 7 差异最明显的地方之一。

首先需要区分三个概念：

它们并不是同一个配置。

5.1 PowerShell 5.1与7的默认编码不同

这张表已经能解释很多常见现象。

例如，同样执行：

"Hello 中文" | Out-File .\\test.txt

在 PowerShell 5.1 和 PowerShell 7 中生成的文件编码可能不同。

因此，不应该把“执行了相同的 PowerShell 命令”理解为“一定生成完全相同的文件字节”。

5.2 什么是BOM？

BOM 是 Byte Order Mark，字节顺序标记。

UTF-8 文件可以包含 BOM，也可以不包含。

UTF-8 BOM 对应的字节为：

EF BB BF

部分 Windows 软件可以利用 BOM 判断文件编码。

但某些跨平台工具、脚本解释器或严格的文本格式处理程序，不希望文件开头出现 BOM。

因此，对于一般的跨平台项目配置文件、JSON、Markdown 和代码文件，通常推荐使用 UTF-8 无 BOM。

但存在一个重要例外：

Windows PowerShell 5.1 读取包含非 ASCII 字符的 .ps1 源文件时，UTF-8 BOM 往往更有利于正确识别编码。

这是一个版本兼容性问题，不能简单地把所有脚本都统一转换为 UTF-8 无 BOM。

5.3 使用明确编码写入文件

PowerShell 7 中可以这样写：

"Hello 中文" |
Set-Content –Path .\\test.txt –Encoding utf8NoBOM

但 utf8NoBOM 不是 Windows PowerShell 5.1 的 -Encoding 参数支持值。

因此，如果希望一段代码能够在 PowerShell 5.1 和 7 中都生成 UTF-8 无 BOM 文件，可以使用 .NET：

$text = "Hello 中文"

$file = Join-Path $env:TEMP "powershell-utf8-test.txt"

$utf8 = [System.Text.UTF8Encoding]::new($false)

[System.IO.File]::WriteAllText(
$file,
$text,
$utf8
)

其中：

[System.Text.UTF8Encoding]::new($false)

表示创建一个不输出 BOM 的 UTF-8 编码对象。

5.4 验证文件编码

读取刚才生成的文件：

[System.IO.File]::ReadAllText(
$file,
[System.Text.Encoding]::UTF8
)

查看文件字节：

Format-Hex –Path $file

如果是 UTF-8 无 BOM，文件开头不会出现：

EF BB BF

这个实验的优点是：

• 不依赖网络；
• 不修改系统配置；
• 在临时目录写入测试文件；
• 能直接验证文件内容和实际字节。

5.5 为什么chcp 65001不能解决所有乱码？

在 Windows 终端中，经常看到这样的命令：

chcp.com 65001

它用于将当前控制台代码页设置为 UTF-8。

但这里有一个重要区别：

控制台代码页不等于文件编码，也不等于所有外部程序的文本编码。

即使代码页是 65001：

• 某些旧版程序仍然可能使用其他编码；
• PowerShell 5.1 的 Out-File 默认行为不会因此自动变成 UTF-8 无 BOM；
• 第三方程序可能具有自己的编码逻辑；
• 已经使用错误编码保存的文件也不会自动修复。

因此，不建议把 chcp 65001 作为所有中文乱码问题的通用修复方案。

5.6 PowerShell与外部程序的编码

PowerShell 还存在一个变量：

$OutputEncoding

它主要影响 PowerShell 通过管道将文本发送给外部程序时使用的编码。

而：

[Console]::OutputEncoding

与控制台输出编码相关。

两者作用不同。

如果确实需要让某个受控开发环境按 UTF-8 与外部程序交换文本，可以先在当前会话进行实验：

$utf8 = [System.Text.UTF8Encoding]::new($false)

[Console]::InputEncoding = $utf8
[Console]::OutputEncoding = $utf8
$OutputEncoding = $utf8

这段设置不应在没有测试的情况下直接复制进所有机器的 Profile。

因为外部程序可能使用自己的编码规则，某些旧程序也可能不完全支持 UTF-8。

遇到中文乱码时，应先确定问题发生在：

• 文件读取；
• 文件写入；
• 标准输入；
• 标准输出；
• 终端字体或渲染。

然后再修改对应层面的配置。

六、集成Git、Node.js、Python和Codex开发工具

PowerShell 环境完成基本配置后，下一步就是验证实际开发工具是否正常。

这里不建议一开始就安装大量终端插件，而是优先保证常用命令稳定可用。

6.1 Git

检查：

Get-Command git –All –ErrorAction SilentlyContinue

如果已安装：

git —version

注意，Git Bash 与 PowerShell 是两种不同的 Shell，但它们都可以调用 Git 可执行程序。

不需要为了使用 Git 而必须切换到 Git Bash。

6.2 Node.js与npm

检查 Node.js：

Get-Command node.exe –ErrorAction SilentlyContinue

如果存在：

node.exe —version

检查 npm：

Get-Command npm –All –ErrorAction SilentlyContinue

以及：

Get-Command npm.cmd –ErrorAction SilentlyContinue

实际运行：

npm.cmd —version

为什么这里推荐先使用 npm.cmd？

因为在 Windows 安装 Node.js 后，可能同时存在：

npm.cmd
npm.ps1

如果当前 PowerShell 解析到了 npm.ps1，而执行策略阻止了它，就可能出现：

npm.ps1 cannot be loaded because running scripts
is disabled on this system.

这种情况不一定意味着 npm 没有正确安装。

可以先验证：

npm.cmd —version

如果 .cmd 入口可以运行，再进一步检查 PowerShell 的命令解析顺序及执行策略。

不建议仅为了运行 npm 就直接关闭 PowerShell 的脚本执行安全检查。

6.3 Python

检查：

Get-Command python.exe –ErrorAction SilentlyContinue

如果存在：

python.exe —version

还可以检查 Python Launcher（如果安装）：

Get-Command py.exe –ErrorAction SilentlyContinue

如果存在：

py.exe —list

注意，在部分 Windows 环境中，python.exe 也可能对应应用执行别名，并不一定是真正安装的 Python 解释器。

因此，应当结合 Get-Command 的路径以及版本输出判断。

创建 Python 虚拟环境时，建议明确当前使用的解释器：

python.exe –m venv .venv

具体命令应在确认 Python 已正确安装后执行。

6.4 Codex CLI

检查：

Get-Command codex –All –ErrorAction SilentlyContinue

如果存在：

codex —version

若 PowerShell 提示无法识别 codex，首先检查命令入口、安装方式与 PATH。

使用 Codex 桌面应用或 IDE 扩展，并不代表一定安装了全局 Codex CLI。

CommandNotFoundException 是命令解析问题，不能据此认定 Codex 网络连接异常。

6.5 为什么需要记录外部命令的退出码？

例如运行：

git —version

可以立即检查：

$LASTEXITCODE

对于通常遵循约定的命令行程序，退出码 0 表示成功，非 0 表示某种失败或异常。

但具体含义要以目标程序的文档为准。

这里还要区分：

$?

与：

$LASTEXITCODE

$? 表示上一条 PowerShell 命令或表达式的成功状态，而 $LASTEXITCODE 记录适用的本机程序退出码。

排查外部程序时，通常建议在调用后立即记录 $LASTEXITCODE，避免把之前程序的退出码误认为本次执行结果。

七、PowerShell 5.1与7之间还有哪些兼容性问题？

除编码外，还有几个值得提前了解的差异。

7.1 &&和||不是所有版本都支持

在 PowerShell 7 中可以使用：

git —version && node.exe —version

但 Windows PowerShell 5.1 不支持这种管道链运算符语法。

如果需要兼容两种版本，建议使用：

git —version

if ($LASTEXITCODE -eq 0) {
node.exe —version
}

这段示例的前提是 Git 和 Node.js 都已安装。

7.2 外部程序参数传递方式存在差异

PowerShell 7.3 对原生命令的参数传递行为进行了调整，改善了某些包含空字符串、嵌套引号的参数处理。

但这也意味着，某些依赖旧行为的脚本可能需要重新验证。

例如，在调用：

curl.exe
git.exe
node.exe
npm.cmd

时，不应假定复杂引号与空参数在 PowerShell 5.1 和 PowerShell 7 中总是具有完全相同的行为。

建议：

• 使用明确的外部可执行程序名；
• 路径中包含空格时正确引用；
• 复杂参数先在目标 PowerShell 版本中验证；
• 不要直接复制 CMD 的特殊语法到 PowerShell。

7.3 旧版Windows模块可能不完全兼容PowerShell 7

部分系统管理模块依赖 Windows PowerShell 5.1 和 .NET Framework。

如果某个模块在 PowerShell 7 中加载失败，应先查看模块的官方兼容性说明。

对于确实依赖旧版环境的工具，继续使用 Windows PowerShell 5.1 是合理的方案。

不需要为了统一版本而强制迁移全部历史脚本。

八、执行策略与脚本安全：不要为方便而关闭保护

在搭建 PowerShell 环境时，还经常会遇到：

PSSecurityException

或者：

running scripts is disabled on this system

这些错误涉及 PowerShell 的执行策略。

首先查看：

Get-ExecutionPolicy

进一步查看不同作用域：

Get-ExecutionPolicy –List

常见执行策略包括：

• Restricted；
• RemoteSigned；
• AllSigned；
• Unrestricted；
• Bypass。

需要注意：

PowerShell 执行策略是纵深防御措施，不是完整的安全边界。

但这并不意味着应该随意关闭它。

尤其在企业环境中，执行策略还可能受到组策略管理。

对于本地开发电脑，应遵循组织或个人的安全要求，不建议为了安装一个工具就直接修改整个系统的执行策略。

如果遇到 npm.ps1 执行受限，可以先检查 npm.cmd 是否能够满足需求。

如果是 PowerShell Profile 无法加载，应检查其来源、签名、有效执行策略及实际文件路径。

对于代码签名、证书信任、UNC 共享路径和 PSSecurityException 的详细分析，后续文章将单独讨论。

九、推荐的PowerShell日常开发配置

前面介绍了大量配置，但并不是每一项都需要修改。

我建议普通 Windows 开发环境采用下面这套相对简单的方案。

9.1 推荐配置

9.2 一个只读的环境检查片段

可以在 PowerShell 中执行：

Write-Host "=== PowerShell ==="

$PSVersionTable |
Select-Object PSVersion, PSEdition

Write-Host "`n=== Commands ==="

$names = @(
"powershell.exe",
"pwsh.exe",
"git.exe",
"node.exe",
"npm.cmd",
"python.exe",
"curl.exe",
"codex"
)

foreach ($name in $names) {
$cmd = Get-Command $name –ErrorAction SilentlyContinue |
Select-Object –First 1

[PSCustomObject]@{
Command = $name
Found = ($null -ne $cmd)
Source = if ($cmd) { $cmd.Source } else { "" }
}
}

Write-Host "`n=== Profile ==="

[PSCustomObject]@{
Path = $PROFILE.CurrentUserCurrentHost
Exists = Test-Path –LiteralPath $PROFILE.CurrentUserCurrentHost
}

Write-Host "`n=== Execution Policy ==="

Get-ExecutionPolicy –List

这段代码不会修改 PATH、Profile 或系统执行策略。

它适合在新电脑上完成基础安装之后执行，也适合在出现命令异常时收集环境信息。

需要注意：

Found = True 只代表当前 PowerShell 能找到相应入口，不代表程序一定能够正常执行全部功能。

例如某个 python.exe 可能是系统的应用执行别名，而不是可用的 Python 安装。

9.3 推荐的验证顺序

#mermaid-svg-GgyCxPw7xnlkCBHg{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-GgyCxPw7xnlkCBHg .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-GgyCxPw7xnlkCBHg .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-GgyCxPw7xnlkCBHg .error-icon{fill:#552222;}#mermaid-svg-GgyCxPw7xnlkCBHg .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-GgyCxPw7xnlkCBHg .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-GgyCxPw7xnlkCBHg .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-GgyCxPw7xnlkCBHg .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-GgyCxPw7xnlkCBHg .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-GgyCxPw7xnlkCBHg .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-GgyCxPw7xnlkCBHg .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-GgyCxPw7xnlkCBHg .marker{fill:#333333;stroke:#333333;}#mermaid-svg-GgyCxPw7xnlkCBHg .marker.cross{stroke:#333333;}#mermaid-svg-GgyCxPw7xnlkCBHg svg{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-GgyCxPw7xnlkCBHg p{margin:0;}#mermaid-svg-GgyCxPw7xnlkCBHg .label{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;color:#333;}#mermaid-svg-GgyCxPw7xnlkCBHg .cluster-label text{fill:#333;}#mermaid-svg-GgyCxPw7xnlkCBHg .cluster-label span{color:#333;}#mermaid-svg-GgyCxPw7xnlkCBHg .cluster-label span p{background-color:transparent;}#mermaid-svg-GgyCxPw7xnlkCBHg .label text,#mermaid-svg-GgyCxPw7xnlkCBHg span{fill:#333;color:#333;}#mermaid-svg-GgyCxPw7xnlkCBHg .node rect,#mermaid-svg-GgyCxPw7xnlkCBHg .node circle,#mermaid-svg-GgyCxPw7xnlkCBHg .node ellipse,#mermaid-svg-GgyCxPw7xnlkCBHg .node polygon,#mermaid-svg-GgyCxPw7xnlkCBHg .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-GgyCxPw7xnlkCBHg .rough-node .label text,#mermaid-svg-GgyCxPw7xnlkCBHg .node .label text,#mermaid-svg-GgyCxPw7xnlkCBHg .image-shape .label,#mermaid-svg-GgyCxPw7xnlkCBHg .icon-shape .label{text-anchor:middle;}#mermaid-svg-GgyCxPw7xnlkCBHg .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-GgyCxPw7xnlkCBHg .rough-node .label,#mermaid-svg-GgyCxPw7xnlkCBHg .node .label,#mermaid-svg-GgyCxPw7xnlkCBHg .image-shape .label,#mermaid-svg-GgyCxPw7xnlkCBHg .icon-shape .label{text-align:center;}#mermaid-svg-GgyCxPw7xnlkCBHg .node.clickable{cursor:pointer;}#mermaid-svg-GgyCxPw7xnlkCBHg .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-GgyCxPw7xnlkCBHg .arrowheadPath{fill:#333333;}#mermaid-svg-GgyCxPw7xnlkCBHg .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-GgyCxPw7xnlkCBHg .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-GgyCxPw7xnlkCBHg .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-GgyCxPw7xnlkCBHg .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-GgyCxPw7xnlkCBHg .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-GgyCxPw7xnlkCBHg .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-GgyCxPw7xnlkCBHg .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-GgyCxPw7xnlkCBHg .cluster text{fill:#333;}#mermaid-svg-GgyCxPw7xnlkCBHg .cluster span{color:#333;}#mermaid-svg-GgyCxPw7xnlkCBHg div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-GgyCxPw7xnlkCBHg .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-GgyCxPw7xnlkCBHg rect.text{fill:none;stroke-width:0;}#mermaid-svg-GgyCxPw7xnlkCBHg .icon-shape,#mermaid-svg-GgyCxPw7xnlkCBHg .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-GgyCxPw7xnlkCBHg .icon-shape p,#mermaid-svg-GgyCxPw7xnlkCBHg .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-GgyCxPw7xnlkCBHg .icon-shape .label rect,#mermaid-svg-GgyCxPw7xnlkCBHg .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-GgyCxPw7xnlkCBHg .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-GgyCxPw7xnlkCBHg .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-GgyCxPw7xnlkCBHg :root{–mermaid-font-family:\”trebuchet ms\”,verdana,arial,sans-serif;}#mermaid-svg-GgyCxPw7xnlkCBHg .blue>*{fill:#DCEBFA!important;stroke:#3678B5!important;color:#183B62!important;}#mermaid-svg-GgyCxPw7xnlkCBHg .blue span{fill:#DCEBFA!important;stroke:#3678B5!important;color:#183B62!important;}#mermaid-svg-GgyCxPw7xnlkCBHg .blue tspan{fill:#183B62!important;}#mermaid-svg-GgyCxPw7xnlkCBHg .gray>*{fill:#F3F5F7!important;stroke:#8A97A5!important;color:#303E4D!important;}#mermaid-svg-GgyCxPw7xnlkCBHg .gray span{fill:#F3F5F7!important;stroke:#8A97A5!important;color:#303E4D!important;}#mermaid-svg-GgyCxPw7xnlkCBHg .gray tspan{fill:#303E4D!important;}#mermaid-svg-GgyCxPw7xnlkCBHg .green>*{fill:#E3F2E8!important;stroke:#41966B!important;color:#20573D!important;}#mermaid-svg-GgyCxPw7xnlkCBHg .green span{fill:#E3F2E8!important;stroke:#41966B!important;color:#20573D!important;}#mermaid-svg-GgyCxPw7xnlkCBHg .green tspan{fill:#20573D!important;}

Windows 开发电脑

检查 PowerShell 5.1 / 7

配置 Windows Terminal

检查 PATH 和命令入口

建立最小 Profile

验证 UTF-8 文件编码

检查 Git / Node.js / Python / Codex

执行只读环境检查

完成配置

图1：Windows PowerShell 开发环境搭建及验证顺序。

这套顺序的主要目的，是让每一步都能够独立验证。

不要一次修改 PATH、Profile、执行策略和编码，然后才测试软件能否运行。

否则一旦出现问题，很难判断是哪项配置造成了变化。

十、常见问题速查

十一、总结

搭建 Windows PowerShell 开发环境，真正重要的不是安装多少插件，而是确保运行环境清晰、工具链一致、配置能够复现。

本文介绍了几个关键原则。

第一，PowerShell 7 与 Windows PowerShell 5.1 应按需共存。

PowerShell 7 更适合新项目和日常开发，5.1 则用于兼容传统 Windows 管理工具。

第二，PATH 问题应先定位命令来源，再考虑修改环境变量。

不要因为命令无法识别，就直接重装软件或覆盖整个 PATH。

第三，Profile 应保持简单。

它适合定义快捷函数和交互习惯，不应承担复杂的项目环境初始化工作。

第四，UTF-8 编码需要区分文件、控制台和外部程序三个层面。

PowerShell 5.1 与 7 的默认文件编码不同，这是许多乱码和跨平台兼容问题的根源。

第五，开发工具应明确运行环境。

Codex、Git、Node.js、Python 等工具应使用明确的版本、路径和依赖环境，避免命令入口冲突。

对于 Windows 原生开发，一个比较实用的组合是：

Windows Terminal + PowerShell 7 + Windows PowerShell 5.1（兼容）+ Git + Node.js + Python + 按需安装的 Codex CLI。

完成基础配置后，再逐步增加项目所需的模块和工具。

下一篇预告

下一篇将介绍：

《PowerShell脚本数字签名实战：自签名证书、代码签名与信任链验证》

重点回答：为什么有些 PowerShell 脚本被阻止执行？如何正确创建代码签名证书、为脚本签名，并验证签名和证书信任？

参考资料

本文属于《Windows 开发环境与 PowerShell 实战》系列，主要分享 Windows 开发工具、命令行自动化、环境配置及常见问题的实际处理方法。