PowerShell（跨平台 Shell）超详细部署指南：安装、升级、源码构建与容器化全流程

PowerShell 是微软开源的跨平台（Windows、Linux、macOS）自动化与配置管理工具及框架。它与你现有的工具配合良好，并针对结构化数据（如 JSON、CSV、XML 等）、REST API 与对象模型做了专门优化。本文基于官方仓库 PowerShell/PowerShell，整理从安装、升级、源码构建到日常使用的完整部署指南。

一、项目介绍

PowerShell 由三部分组成：一个命令行 Shell、一门配套的脚本语言，以及一套用于处理 Cmdlet（命令行工具，读作"command-let"）的框架。与传统 Shell 主要面向文本流不同，PowerShell 的命令输出是 .NET 对象——你可以直接对输出的属性、方法进行操作，而不必用文本工具反复切割解析，这让它在处理结构化数据时格外高效。

这种"一切皆对象"的设计是 PowerShell 区别于 bash、cmd 的根本所在：管道传递的不是一坨字符，而是带类型的 .NET 对象，因此下一个 Cmdlet 可以直接按属性名取数据、调用方法，天然适合对接 JSON、CSV、XML 与 REST API 返回的结构化结果。运维人员常用它完成批量用户管理、日志分析、服务器配置、CI 任务编排等工作。

举个直观的例子：在传统 Shell 里想找出占用内存最高的几个进程，往往要 ps 再接 awk、sort、head 一串文本处理；而在 PowerShell 中，Get-Process | Sort-Object WorkingSet -Descending | Select-Object -First 5 Name,Id,WorkingSet 一步即可完成，因为每个进程本身就是一个带 Name、Id、WorkingSet 属性的对象。这种表达方式既强大又易读。

需要特别区分两个概念：Windows PowerShell 是随 Windows 系统自带的旧版本（最高到 5.1），而本仓库维护的是 PowerShell 7+（常称 PowerShell Core）。这个仓库最初从 Windows PowerShell 代码库分叉而来，但这里的修改不会回移植到 Windows PowerShell 5.1。也就是说，本仓库跟踪的 issue 仅针对 PowerShell 7.x 及以上版本；Windows PowerShell 5.1 相关问题应通过系统的"反馈中心"应用提交。

PowerShell 7+ 基于 .NET（.NET Core）构建，因此真正实现了跨平台：同一条脚本可以在 Windows、Linux 与 macOS 上运行。它采用 MIT 许可证开源，是微软开发者与运维生态的重要基础组件。社区还通过公共仪表盘可视化地展示贡献与项目状态。

与 bash 等 Unix Shell 相比，PowerShell 的学习曲线略陡，因为它同时引入了面向对象与 .NET 生态；但一旦熟悉了"动词-名词"命名与管道传对象的思维方式，你会发现它在系统管理与自动化上表达力极强。微软官方为初学者准备了入门学习文档，建议新用户先过一遍再动手写脚本。

PowerShell 7.5 在终端中的运行效果

二、项目结构

PowerShell 仓库是一个典型的 .NET 大型项目，克隆后主要包含：

src/：核心源代码，包含引擎、Cmdlet 实现（如 Microsoft.PowerShell.Commands.Utility 等程序集）、语言解析器与运行时。
assets/：品牌图标等资源，例如仓库根 README 引用的 ps_black_64.svg PowerShell 标志。
docs/：开发文档，其中 docs/building/ 下分平台给出了 Linux、Windows、macOS 的构建说明，另有 docs/FAQ.md 收集常见问题。
.github/：贡献指南、支持说明与安全策略等。
相关仓库：设计讨论放在 PowerShell-RFC；SDK 相关问题见仓库 FAQ。

对普通用户而言，无需接触源码——直接安装发布包即可；只有当你想贡献代码、定制构建或研究引擎实现时，才需要克隆完整仓库并按对应平台文档编译。

社区协作方面，PowerShell 在 GitHub Discussions 中进行与代码无关的开放讨论，并在 Discord、Libera.Chat IRC、Slack 上设有多个主题频道；设计层面的重大改动则通过 PowerShell-RFC 仓库以"征求意见稿"的形式公开评审。

三、版本与环境要求

PowerShell 7+ 支持 Windows、macOS 以及多种主流 Linux 发行版（如 Debian、Ubuntu、CentOS、RHEL、Fedora 等）。具体支持的操作系统版本与包格式，以官方安装文档为准。由于它基于现代 .NET，对老旧系统（如已停止支持的 Windows 7、或过旧的 glibc 版本）的支持会随 .NET 版本演进而调整，安装前建议核对官方列出的支持矩阵。

运行 pwsh 后，可随时用 $PSVersionTable 查看当前会话的版本信息；$PSVersionTable.PSVersion 给出具体版本号，PSEdition 显示为 Core 即代表 PowerShell 7+。这是排查"我到底在用哪个版本"最直接的方式。

升级时的一条重要经验是：尽量沿用你最初安装 PowerShell 时所用的方式来升级。因为不同安装方式（MSI 安装包、各发行版官方仓库、直接下载二进制、Dotnet 工具等）的更新机制各不相同，混用可能导致系统里同时存在多个版本或找不到更新入口。

此外，PowerShell 默认会收集遥测数据（发送到微软的匿名使用统计），详情可参阅官方 about_Telemetry 说明；在无人值守的 CI 或 Docker 场景中，通常会通过环境变量 POWERSHELL_TELEMETRY_OPTOUT=1 关闭。

四、本地部署

方式一：各平台包管理器 / 官方仓库（推荐）

Windows 上可通过 MSI 安装包或 winget 安装；macOS 上可通过 Homebrew 的 cask 或官方 pkg 安装；Linux 下微软为各发行版提供了官方包仓库（apt、dnf、yum、zypper 等），添加仓库后即可用系统包管理器安装并随系统升级。完整命令请参考官方安装 PowerShell 文档，因为各发行版的源配置步骤会随时间更新。

以 Windows 为例，安装完成后开始菜单里会出现"PowerShell 7"，终端命令为 pwsh（区别于旧版的 powershell）。Linux/macOS 下安装成功后，直接在终端输入 pwsh 即可进入新的 Shell 会话；用 $PSVersionTable 命令可以查看当前版本号、版本类型（Core 即 PowerShell 7+）、操作系统与 CLR 版本等关键信息。

方式二：直接下载二进制压缩包

在没有包管理器、或需要在隔离环境中使用时，可从 GitHub Releases 下载对应平台的 tar.gz / zip 压缩包，解压后即可运行其中的 pwsh（Linux/macOS）或 pwsh.exe（Windows）。这种方式无需管理员权限，适合绿色使用。

Linux/macOS 下解压后，进入目录执行 ./pwsh 即可启动；若希望全局可用，可把整个目录放到固定路径并把该路径加入 PATH，或软链接到 /usr/local/bin/pwsh。这种方式的缺点是不会自动更新，需要你定期手动下载新版替换。

方式三：从源码构建

克隆仓库：

git clone https://github.com/PowerShell/PowerShell.git
cd PowerShell

之后按平台选择构建说明：Linux 看 docs/building/linux.md，Windows 看 docs/building/windows-core.md，macOS 看 docs/building/macos.md。构建前需准备好 .NET SDK；遇到问题先查阅开发 docs/FAQ.md。关于如何与该仓库协作，见 working with the PowerShell repository。

源码构建主要面向想贡献代码或研究引擎的开发者。对绝大多数用户，直接用包管理器或 Releases 二进制即可，既快又省心；从源码编译不仅耗时长，还需要对应平台的开发工具链，不建议普通用户为了"用 PowerShell"而走这条路。

方式四：Docker 容器

需要注意一个重要变更：PowerShell 容器镜像现已改由 .NET 团队维护，旧的 mcr.microsoft.com/powershell 镜像目前不再维护。使用容器前，请确认你拉取的是当前受支持的镜像标签，并阅读 Microsoft Artifact Registry 上的许可说明。

容器方式非常适合 CI/CD：把 PowerShell 环境固化进镜像，流水线拉起来即可执行脚本，不受宿主机系统差异影响。官方镜像默认以非交互方式运行 pwsh，可直接把要执行的脚本作为启动命令传入。

PowerShell 命令行界面

五、浏览器端部署

PowerShell 本身是一个需要本地运行时的 Shell，并不提供官方的"网页版 PowerShell"。不过，你可以通过 Azure Cloud Shell 在浏览器中直接使用 PowerShell 环境：登录 Azure 门户后打开 Cloud Shell，即可在浏览器标签页里选择 PowerShell 模式，免安装地执行云端资源管理命令。它适合临时管理 Azure 资源或在没有本机环境的设备上跑一段 PowerShell。

对于 CI/CD 与服务器自动化场景，更常见的做法是把 PowerShell 安装在构建容器或远程主机上，通过 SSH / WinRM 远程执行，而不是在浏览器里长期使用。浏览器内可用的具体能力与配额以 Azure Cloud Shell 官方文档为准。

此外，GitHub Actions、Azure DevOps 等流水线平台的运行器里通常已预装 PowerShell，你可以直接在流水线中编写 pwsh 步骤完成构建、测试与部署，这也是 PowerShell 在现代 DevOps 中最常见的"部署"形态之一。

六、API 用法

Cmdlet 与脚本语言：PowerShell 的基本单位是"动词-名词"命名的 Cmdlet，例如 Get-ChildItem（列目录）、Get-Service（查服务）、Select-Object（选属性）、Where-Object（过滤）。它们通过管道 | 串联，传递的是对象而非纯文本。例如 Get-Service win* | Where-Object { $_.Status -eq 'Running' } 即可筛出正在运行的服务。

常用别名：为了照顾从 Unix 或 cmd 迁移的用户，PowerShell 提供了大量别名，如 ls、cat、cd，背后实际映射到对应的完整 Cmdlet。脚本中建议使用完整 Cmdlet 名以提高可读性。

PowerShell SDK（NuGet）：如果你在开发面向 PowerShell Core 的 .NET 应用，可以使用 PowerShell SDK 的 NuGet 包把 PowerShell 引擎嵌入自己的程序中，以编程方式执行命令、收集输出。具体获取方式见仓库 FAQ 的"Where do I get the PowerShell Core SDK package"一节。这一能力常用于让 .NET 产品自带脚本扩展能力，或在应用内部自动化调用运维 Cmdlet。

帮助系统：随时用 Get-Help 命令名 查看某个 Cmdlet 的用法与示例，加 -Examples 只看示例；用 Get-Command 按关键字搜索可用命令。这套内建帮助是学习 PowerShell 最权威的本地参考。

远程处理与自动化：PowerShell 支持 Remoting（基于 WinRM 或 SSH），可在多台主机上批量执行配置管理；结合 DSC（期望状态配置）与各种模块，可完成服务器的自动化部署与合规检查。

脚本与模块：PowerShell 脚本以 .ps1 为扩展名，支持变量、流程控制、函数、错误处理（try/catch）与管道；可复用的功能通常封装为模块（.psm1），通过 Import-Module 加载。官方与社区提供了海量模块（如 Azure、AWS、Exchange、Windows 管理模块），覆盖云资源管理、办公自动化等场景。

七、常见问题（FAQ）

Q1：PowerShell 7 和 Windows PowerShell 5.1 是一回事吗？我该用哪个？
不是。Windows PowerShell 5.1 是系统自带的旧版本，停止在 5.1；PowerShell 7+ 是本仓库维护的跨平台新版本，持续更新。日常写新脚本、做跨平台自动化，建议安装 PowerShell 7+；系统里仍会保留 5.1 供旧脚本兼容。两者命令名分别是 pwsh 与 powershell，可以同时存在互不影响。

Q2：为什么升级后行为不对 / 找不到新版本？
官方建议沿用最初的安装方式升级。如果你当初用 MSI 装的，就去下载新版 MSI；如果用 Linux 官方仓库装的，就用 apt upgrade / dnf upgrade。混用安装方式容易造成多版本并存。

Q3：脚本执行被策略拦截提示"未对系统进行签名"？
这是 PowerShell 默认的执行策略（Execution Policy）限制。对本地编写的脚本，可在当前用户范围设置为 RemoteSigned（本地脚本可运行，远程下载脚本需签名）。注意这只是一个安全护栏，不是系统内核限制。

Q4：Docker 拉取 mcr.microsoft.com/powershell 后发现很久没更新？
因为该镜像现已交由 .NET 团队维护，旧标签不再更新。请改用当前受支持的镜像标签，具体以 Microsoft Artifact Registry 与官方公告为准。

Q5：如何关闭遥测？
设置环境变量 POWERSHELL_TELEMETRY_OPTOUT=1 后再启动 pwsh 即可。容器场景通常在 Dockerfile 或 compose 中预置该变量。

Q6：Windows 上 PowerShell 7 里用 Appx 模块报错怎么办？
在 PowerShell 7+ 中使用 Add-AppxPackage 等应用打包相关命令前，需要先执行 Import-Module Appx -UseWindowsPowerShell，因为这些模块仍依赖 Windows PowerShell 5.1 承载，PowerShell 7 会通过兼容性会话调用它们。

常见报错与解决：运行 pwsh 提示"找不到命令"，多半是未把安装目录加入 PATH，或解压后未使用完整路径；在 Windows 7+ 手动安装时缺少依赖可先安装所需的通用运行时；跨平台脚本里若误用了 Windows 专有的 Cmdlet（如访问注册表），在 Linux/macOS 上会报错，应改用跨平台兼容的模块。提示"执行策略更改"时，按上面 Q3 调整当前用户的执行策略即可；若脚本里调用了尚未安装的模块，用 Install-Module 从 PowerShell Gallery 安装对应模块。遇到构建问题，请先看仓库 docs/FAQ.md 与 GitHub Issues。