企业官网建设流程全解析

1. 为什么Windows用户都该学一下PowerShell

如果你和我一样，平时需要在Windows上装软件、查日志、批量改文件、配开发环境，那你迟早会碰上PowerShell。简单说，PowerShell是微软在Windows上主推的命令行环境和脚本语言，它比老旧的CMD（命令提示符）强大太多，而且和Windows系统的关系非常深。从Windows 7开始，系统自带的PowerShell 2.0，到Win10/11默认预装PowerShell 5.1，再到现在跨平台的开源PowerShell 7，它几乎是所有Windows自动化操作的地基。

这门技术适合谁？我的看法是，只要你用过电脑，就值得花半小时认识它。IT运维、后端开发、数据分析师会把它当日常工具使；普通用户哪怕只会用几条命令，也能解决很多"点鼠标点到手酸"的问题，比如批量重命名文件、一键清理临时目录、快速查看端口占用。PowerShell入门不要求你先会编程，它和CMD一样可以一条命令一条命令地敲，但它的上限又极高——你完全能用它写出成百上千行的自动化脚本，把重复劳动全部交给机器。

可能你会问，Windows图形界面这么成熟，为什么还要学命令行？我的真实体会是，很多事情用图形界面做一次两次还行，一旦要重复一百次、要定时执行、要跨机器远程执行，命令行脚本才是唯一可靠的出口。而且PowerShell不是独立于系统之外的东西，它就是Windows管理理念的一部分，系统日志、防火墙规则、计划任务、IIS、Active Directory、云平台管理，统统都有对应的PowerShell模块。换句话说，学PowerShell不是学一个"小工具"，而是在学Windows系统的底层管理语言。

后面我会从最基础的概念讲起，逐步带你走一遍实际使用中最高频的操作，最后把常见的报错和坑一并列出来。我想尽量写得像面对面聊天一样，把我踩过的坑、验证过的命令、用过之后留下的习惯都告诉你。

2. 从入门到真正上手：PowerShell的核心概念

2.1 PowerShell和CMD到底差在哪

很多第一次接触PowerShell的人，都会先拿它和CMD做对比。表面上两者都是在黑色窗口里敲命令，但底层逻辑完全不同。CMD是一个命令解释器，它执行的批处理命令本质上是"字符串处理"，你输入一条命令，它把命令文本交给系统去执行，输出也全是文本。PowerShell则建立在.NET框架之上，它内部处理的是"对象"，命令本身是一个个叫做"Cmdlet"的完整函数。

我打个比方。CMD就像你打电话给一个客服，你只能按语音提示按键，对方给你播报结果；PowerShell则像直接和一位熟练的技术人员对话，你可以让他在后台把数据整理成表格、筛选、排序，再把结果返回给你。这种设计带来一个根本性的变化：PowerShell里的命令可以互相传递结构化数据，而不是传递一堆需要自己解析的文本。比如你运行一个命令拿到10个进程的信息，在CMD里要拼字符串、用findstr去过滤；在PowerShell里，进程信息就是一个个对象，你可以直接用命令筛选、计数、导出CSV，甚至逐个调用它们的方法。

另外，PowerShell的语法更接近现代编程语言，它有变量、数组、哈希表、函数、条件判断、循环、异常处理。这意味着它不仅仅是"能用的工具"，更是"能写程序的语言"。从Windows 10开始，微软甚至把PowerShell作为系统默认的终端之一，许多图形界面下的管理工具，背后调用的其实就是PowerShell命令。所以早点熟悉它，你会发现系统很多"神秘行为"突然变得可以理解了。

2.2 对象化管道：一句话实现"按条件筛选再处理"

PowerShell里最核心的一个概念是管道，语法上用竖线"|"连接两条命令。CMD其实也有管道，但CMD管道传递的只是文本流，而PowerShell管道传递的是对象。这个差异怎么理解呢？我给你看一个实际例子。

假设我想把所有占用内存超过100MB的进程暂停掉，在PowerShell里可以这样写：

Get-Process | Where-Object { $_.WorkingSet64 -gt 100MB } | Stop-Process -Force

这条命令拆开来看，Get-Process拿到所有进程对象，Where-Object按条件筛选，$_代表当前正在处理的那个进程对象，WorkingSet64是内存占用，然后筛选结果继续传给Stop-Process。整个过程不需要知道进程信息长什么样、不需要解析文本，对象天然携带了所有字段和方法。这在CMD里几乎不可能一行搞定。

再比如，我经常要找出当前目录下大于1GB的文件，然后按大小排序显示：

Get-ChildItem -Recurse | Where-Object { $_.Length -gt 1GB } | Sort-Object Length -Descending | Select-Object FullName, @{Name='SizeMB';Expression={[math]::Round($_.Length/1MB,2)}}

这就是"对象化管道"的魅力。每一条命令的输出对象，都能被下一条命令直接使用，你要做的就是理解当前对象有哪些属性、哪些方法。多用几次Get-Member命令，就能看到对象的全貌：

Get-Process | Get-Member

它会列出进程对象的所有属性、方法和事件名称。这个命令是我个人用得最多的"探索工具"，遇到不确定的返回值，先Get-Member看一下，比翻文档还快。

2.3 别名与高频命令速查

PowerShell允许你使用别名，很多习惯Linux命令的人会很快上手，因为PowerShell贴心地为常见命令起了别名。比如：

• Get-ChildItem的别名是ls或dir
• Copy-Item的别名是cp或copy
• Remove-Item的别名是del或rm
• Set-Location的别名是cd
• Get-Content的别名是cat或type

用别名并不会损失功能，所以你可以完全按照自己熟悉的习惯来敲。不过我的建议是，刚开始学习时尽量用完整的Cmdlet名称，比如Get-ChildItem、Get-Process，因为完整名称是有规律的"动词-名词"结构，看名字就能猜出大概用途。等形成肌肉记忆后，再用别名提速也不迟。

这里列一份我日常使用频率最高的命令表，堪称"PowerShell生存指南"：

需要说明的是，Get-Help是全中文的，遇到不认识的命令，先敲一句Get-Help命令名 -Online直接打开在线文档，这是最快的学习路径。

3. 环境准备与启动技巧

3.1 先确认你的PowerShell版本

每次我帮别人排查PowerShell问题，第一件事就是让对方确认版本。不同版本的命令、参数、行为差异比想象中大得多。查看版本很简单，在PowerShell窗口里输入：

$PSVersionTable

这会返回一个表格，重点关注PSVersion这一行。Windows 7自带的是PowerShell 2.0，Win8/8.1是4.0，Win10/11默认是5.1，而最新的大版本是7.x。如果有条件，我非常建议升级到PowerShell 7以上，后面我会专门说原因。

确认版本还有一个实际意义：如果你拿到的脚本明明在别人机器上跑得好好的，到你这里就报错，大概率是版本不一致。比如某些Get-NetAdapter、Get-NetIPAddress这类管理网络适配器的命令，老版本PowerShell里就没有，因为对应的模块是从Windows 8.1才开始内置的。

3.2 快速启动PowerShell的几种姿势

启动PowerShell的方法很多，我挑几个最好用的说出来。

第一，快捷键启动。按下Win + X，在弹出的快捷菜单中选择"Windows PowerShell"或"终端"（Windows 11里往往是"终端"），这时候打开的就是PowerShell环境。如果你经常用，我建议把它固定到任务栏。

第二，在文件夹里打开。在文件资源管理器地址栏输入powershell.exe，回车，就会直接在该目录下打开PowerShell窗口，省去先打开窗口再cd到目标目录的麻烦。这个技巧我在处理项目文件、脚本文件时每天都在用，实测非常顺手。

第三，用"运行"对话框。按Win + R，输入powershell，可以快速打开。如果你需要管理员权限，按下Ctrl + Shift + Enter以管理员身份运行即可。

你也可以在标题栏或快捷方式上右键，选择"以管理员身份运行"。很多操作——比如修改执行策略、安装系统组件、操作服务——都要求管理员权限，否则会报"拒绝访问"。

3.3 5.1和7到底选哪个

这是一个新手很容易纠结的问题。我的结论是：日常使用、写脚本、跑自动化，优先装PowerShell 7；但有一些老模块、老脚本还是依赖Windows自带的Windows PowerShell 5.1，所以两台不要觉得装了7就能砍掉5.1，最好两个都留着。

PowerShell 7是基于.NET Core（后来叫.NET 5+）开发的跨平台版本，官方在GitHub上开源，支持Windows、Linux、macOS。它的主要优势是性能快很多，操作对象的效率比5.1高，新增了很多实用运算符和错误处理机制，而且完全向下兼容5.1的大多数命令。最关键的是，它和5.1可以共存，启动方式也不同：5.1的启动程序是powershell.exe，7的启动程序是pwsh.exe。

所以你可以这样理解：系统自带的5.1是"系统底座"，很多Windows组件和旧脚本会调用它；你自己日常干活、写新脚本，用7更舒服。升级到7也简单，在PowerShell里执行：

winget install Microsoft.PowerShell

或者在官网下载安装包都行。安装完再输入$PSVersionTable，看到的版本就是7.x了。

4. 日常运维场景实操

4.1 实现开机自启脚本

先讲最常见的一个需求：开机时自动执行某个PowerShell脚本。很多人第一反应是放到"启动"文件夹，但那样弹出的黑色窗口很突兀，而且执行权限容易被限制。我推荐用"任务计划程序"来搞定，它更可靠，还能设定触发条件。

首先写一个简单的脚本，假设是C:\Scripts\startup_task.ps1，内容比如清理临时文件：

$tempPaths = @( "$env:TEMP\*", "C:\Windows\Temp\*" ) foreach ($path in $tempPaths) { Remove-Item $path -Recurse -Force -ErrorAction SilentlyContinue } Add-Content -Path "C:\Scripts\startup.log" -Value "$(Get-Date) 清理完成"

然后打开任务计划程序，依次操作：创建基本任务、填名称、触发器选"当计算机启动时"、操作选"启动程序"、程序填powershell.exe，参数填-ExecutionPolicy Bypass -File "C:\Scripts\startup_task.ps1"，最后勾选"使用最高权限运行"。

这里的-ExecutionPolicy Bypass参数很关键，它能让本次脚本运行绕过系统默认的执行策略限制，避免脚本因为策略问题被拦截。如果你不想每次传这个参数，也可以提前修改全局执行策略，这个在下一章会细讲。

4.2 查看CPU温度与硬件信息

很多人搜索"PowerShell查看CPU温度"，这其实是个有点尴尬的需求：PowerShell本身没有一个独立的命令能直接读取CPU温度传感器，因为温度数据来自硬件传感器，需要厂家驱动和WMI类的支持。不过我们可以借助WMIC或Get-CimInstance拿到一部分硬件信息，再配合第三方组件读取温度。

至少这些信息用纯PowerShell能拿到：

Get-CimInstance Win32_Processor | Select-Object Name, NumberOfCores, MaxClockSpeed Get-CimInstance Win32_GraphicsController | Select-Object Name, AdapterRAM Get-CimInstance -ClassName Win32_Battery | Select-Object EstimatedChargeRemaining

至于温度，我实测过两个方案：一是用开源工具OpenHardwareMonitor，它提供了本地Web服务，PowerShell可以请求它的接口拿到数据；二是用一些品牌笔记本自带的传感器WMI类，但通用性因机型而异。如果你只是想知道当前电脑热不热，更省事的办法是直接读主板和传感器厂商的监控软件，或者用Get-Counter读性能计数器里的"Thermal Zone Temperature"：

Get-Counter '\Thermal Zone Temperature(*)'

这个命令在某些笔记本上能返回温度值，单位是开尔文，需要减273.15转成摄氏度。我在自己台式机上试过，返回的是传感器区域温度，不是CPU核心温度，但作为参考已经够用了。想读CPU核心温度，目前还是得靠HWiNFO这类工具导出数据，PowerShell再读取。

4.3 打包与解压：gz文件一样能处理

有人问"PowerShell能打包gz文件吗"，答案是可以。PowerShell中处理压缩文件最常用的命令是Compress-Archive，但它默认生成的是zip格式，不能直接生成tar.gz。不过从PowerShell 5.x开始，系统内置了tar.exe和tar命令（Windows 10 1803之后自带），所以你可以这样组合使用：

# 先用tar打包成tar文件 tar -cvf myfiles.tar C:\data\files # 再用gzip压缩（在PowerShell中调用gzip需要额外工具，或直接用tar的-z参数） tar -czvf myfiles.tar.gz C:\data\files

实测中，Windows自带的tar.exe支持-z参数直接生成gzip压缩的tar包，这就能满足"打包gz文件"的需求了。如果你要处理的不是tar.gz而是单纯的.gz文件，比如解压一个数据集的.gz文件，可以借助.NET库：

function Expand-GZipFile { param([string]$FilePath) $input = [System.IO.File]::OpenRead($FilePath) $output = [System.IO.File]::Create(($FilePath -replace '\.gz$', '')) $gzip = [System.IO.Compression.GZipStream]::new($input, [System.IO.Compression.CompressionMode]::Decompress) $gzip.CopyTo($output) $gzip.Dispose(); $output.Dispose(); $input.Dispose() } Expand-GZipFile -FilePath "C:\data\dataset.csv.gz"

这段代码用了.NET的GZipStream类，写起来有点绕，但非常通用。我的建议是：日常压缩首选Compress-Archive生成zip，因为Windows资源管理器直接双击就能解压；遇到服务器上常见的tar.gz文件，直接调用内置tar命令，不要自己造轮子。

4.4 管理服务、进程、端口

管理服务是运维同学最常用的场景。查看服务用Get-Service，操作服务用Start-Service、Stop-Service、Restart-Service，配合条件筛选可以批量操作。比如我想把一堆名字以"SQL"开头的服务全部停止：

Get-Service -Name "SQL*" | Where-Object Status -eq "Running" | Stop-Service -Force

进程管理类似。用Get-Process找到目标进程，Stop-Process结束它。定位端口占用更是高频需求，比如我经常碰到"端口8080被占用，启动服务失败"，在PowerShell里可以这样查：

Get-NetTCPConnection -LocalPort 8080 -State Listen | Select-Object LocalAddress, LocalPort, OwningProcess

拿到OwningProcess即PID之后，再查是哪个进程：

Get-Process -Id <PID>

如果你想一步到位，可以使用之前静默安装的Windows工具集里的netstat命令配合PowerShell对象处理：

netstat -ano | Select-String ":8080"

但netstat输出的是纯文本，解析起来不如Get-NetTCPConnection方便。我建议在PowerShell里优先用Get-NetTCPConnection，对象化字段查询起来更容易。

4.5 配套开发工具的环境准备

现在很多开发工具的Windows安装脚本都依赖PowerShell。比如使用Docker、Elasticsearch、Redis、Git等工具时，常见做法是先执行一段PowerShell初始化命令。这类工作在5.1和7上会有一些行为差异，但核心思路是一致的：先把命令执行策略放开，再执行安装脚本。

以使用winget举例，它是Windows官方的包管理命令行工具，默认集成在Win10/11里。你可以用它批量安装开发环境：

winget install Git.Git winget install Docker.DockerDesktop winget install Microsoft.PowerShell

另外，很多工具在Windows下初次配置时，会遇到PowerShell版本过旧或模块未安装的问题。此时我习惯先执行一条系统更新模块命令：

Install-Module -Name PowerShellGet -Force

这个命令会更新包管理模块本身，之后再安装其他模块就会顺畅很多。注意Install-Module可能需要管理员权限，而且要确认NuGet提供程序已经安装，如果提示安装，输入Y确认即可。

我在配置新电脑时，通常会把Windows Terminal、PowerShell 7、Git、Docker Desktop等一次装齐，然后把下面的内容写进PowerShell配置文件，让每次启动终端时都自动加载常用模块和别名：

# 查看配置文件路径 $PROFILE # 如果文件不存在则创建 if (!(Test-Path -Path $PROFILE)) { New-Item -ItemType File -Path $PROFILE } # 在配置文件里添加常用别名 Add-Content -Path $PROFILE -Value "Set-Alias -Name touch -Value New-Item"

这样之后用PowerShell写脚本、跑自动化、配合Git和容器工具，整个工作流会比纯图形界面顺滑很多。

5. 写脚本的常见坑与排查实录

5.1 卡住多年的Set-ExecutionPolicy执行策略错误

很多新手第一次运行PowerShell脚本，就撞上这行红字：

无法加载文件 xxx.ps1，因为在此系统上禁止运行脚本。

这个问题的根源是Windows默认将脚本执行策略设为Restricted，禁止运行任何.ps1脚本文件。解决方法是用Set-ExecutionPolicy修改策略。

我的建议是把策略设为RemoteSigned，即本地创建的脚本允许运行，从网络下载的脚本必须经过数字签名。这是安全性和便利性的平衡点：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

注意-Scope CurrentUser，只对当前用户生效，不用动系统级设置，也不需要管理员权限。如果某个脚本确实从网上下载，运行前可以用Unblock-File解锁：

Unblock-File -Path "C:\Scripts\downloaded.ps1"

这个命令会去除文件被标记为"来自网络"的Zone.Identifier属性，之后脚本就能正常运行了。

还有一个高频场景：Git等工具在安装时会尝试运行PS脚本，如果被拦截，那就在启动命令时显式加上-ExecutionPolicy Bypass，实测能绕过大部分问题。例如：

powershell -ExecutionPolicy Bypass -File "C:\Scripts\init.ps1"

5.2 中文乱码：从编码根源解决问题

"PowerShell乱码"是搜索榜单上的常客，尤其是当你用PowerShell读取UTF-8无BOM文件、或者运行某个输出中文的程序时，经常看到一堆乱码。

先说最典型的情况：PowerShell 5.1默认使用系统区域编码（通常中文系统是GBK/GB2312），而现代工具和脚本大多用UTF-8。两者不一致，显示就乱了。解决方法也很简单，在脚本开头或交互式窗口里设置编码：

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

如果你在用PowerShell 7，情况好很多，它默认就是UTF-8，极少出现乱码。所以如果你被乱码问题困扰良久，升级到7往往是最省心的解法。

另外，有时候不是显示问题，而是脚本本身读取文件时把编码搞错了。比如用Get-Content读取UTF-8文件，在5.1里就会乱。此时显式指定编码：

Get-Content -Path "C:\data\config.json" -Encoding UTF8

写文件同理，用Set-Content -Encoding UTF8。我在配置一些开发工具时，明明文件内容是对的，工具却报解析错误，最后发现是PowerShell把这个文件写成了带BOM的UTF-8，而工具不支持BOM。处理办法是把默认编码改成无BOM的UTF-8：

$PSDefaultParameterValues['Out-File:Encoding'] = 'utf8NoBOM'

这个细节非常容易踩坑，建议记录下来。

5.3 双击脚本闪退的三个排查方向

双击一个.ps1脚本，黑色窗口一闪而过，什么都没留下，这是新手特别犯愁的问题。其实脚本很可能执行了，只是因为写得不够健壮，或者被执行策略拦截，而窗口秒关看不到报错内容。

排查方向有三。第一，确认是不是执行策略拦截，用上一节的方法临时Bypass再运行一次。第二，脚本里如果有异常，窗口会退出，所以在脚本末尾加一行Read-Host 'Press Enter to exit'，让窗口等待回车关闭，这样就能看到报错了。第三，检查脚本是不是被系统标记为来自网络，用Unblock-File解锁。

我个人的习惯是，写脚本时永远在开头加上这几行，确保任何错误都能被看到：

$ErrorActionPreference = "Stop" try { # 你的逻辑 } catch { Write-Host $_.Exception.Message -ForegroundColor Red Read-Host "Press Enter to exit" }

这样即使出错了，也不会一闪而过，而是把错误信息留在屏幕上。另外我还要提醒一句，永远不要在未设置执行策略的机器上直接双击ps1脚本，要么右键"使用PowerShell运行"，要么在已打开的PowerShell窗口里执行脚本，后者的体验会更好。

5.4 安装PowerShell报错-2146869246怎么办

有人安装PowerShell时遇到"安装程序无法安装 Windows PowerShell。错误代码为 -2146869246。"这个错误。我在网上查过大量资料，也在几台Windows 7老机器上遇到过。这个错误码转换成十六进制是0x80070002，含义是"系统找不到指定的文件"。

大多数情况下，这个报错出现在旧版PowerShell安装包解压或安装过程中，根源是系统缺少必要的更新补丁或.NET框架组件。比如Windows 7要安装PowerShell 5.1，必须先安装WMF 5.1，而WMF 5.1需要.NET Framework 4.5以上，同时也依赖KB2506143、KB2533623这些基础补丁。如果这些前置条件没满足，安装程序就会报"找不到指定的文件"，翻译成人类语言就是"字面意思：缺东西，但我不告诉你是谁"。

解决方法按顺序做：

1. 确认系统更新打到最新，Windows 7至少装上SP1。
2. 安装.NET Framework 4.5.2或更高版本。
3. 安装WMF 5.1安装包，注意区分x86/x64，别下错。
4. 安装完成后重启，再执行$PSVersionTable确认版本。

如果你查遍了更新、也装了.NET还是报同样错误，还有一招是用Windows Update手动安装"Microsoft Windows 更新程序和安全修补程序"，或者在系统日志里找到安装失败的具体组件名字。这个错误没有万能药，多半就是环境不完整，按依赖顺序补齐就能解决。

6. 从会用走向自动化运维

6.1 用计划任务把PowerShell脚本定时跑起来

很多人让PowerShell"开机自启"只解决了自动运行的第一步，更常见的需求是按周期执行，比如每天凌晨备份文件、每周五压缩日志。这类定时任务最稳的实现方式是用Windows计划任务程序，配合PowerShell脚本。

除了在图形界面里逐项配置，你也可以用PowerShell自带命令直接注册计划任务。比如我想创建一个名为"DailyBackup"的任务，每天21点运行备份脚本：

$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy Bypass -File C:\Scripts\backup.ps1" $trigger = New-ScheduledTaskTrigger -Daily -At 21:00 $principal = New-ScheduledTaskPrincipal -UserId "SYSTEM" -LogonType ServiceAccount -RunLevel Highest Register-ScheduledTask -TaskName "DailyBackup" -Action $action -Trigger $trigger -Principal $principal

这里的-RunLevel Highest用来以最高权限运行，UserId "SYSTEM"则是用系统账户执行，不依赖某个用户是否登录。注册之后，你可以在任务计划程序里看到它，也可以立即手动运行一次验证。

需要提醒的是，计划任务里的PowerShell脚本如果涉及网络路径、映射驱动器，常会遇到权限落差导致找不到路径。我的做法是在脚本开头先New-PSDrive把网络共享映射一次，或者直接使用UNC路径加上-Persist参数。

6.2 用PowerShell分析Windows安全日志

再说一个进阶场景：安全日志分析。Windows事件日志里记录了登录成功/失败、服务启动、系统关闭等大量信息，图形界面查看很不方便，PowerShell却能轻松筛选。比如查看最近10条系统日志：

Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=(Get-Date).AddDays(-1)} -MaxEvents 10

如果事件日志量很大，推荐用-FilterHashtable，它比Where-Object慢查询高效得多。登录失败事件通常有ID 4625，登录成功是4624，锁屏、解锁是4800、4801，这些事件ID在安全日志里非常关键。一条典型查询：

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-24)} | Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List

这样能快速定位一天内所有登录失败的记录，以及失败原因、来源IP。在我做故障排查时，这条命令配合导出CSV给同事分析，非常顺手。注意读取安全日志需要管理员权限，之前就有人问"为什么Get-WinEvent报拒绝访问"，十有八九是权限不够。

6.3 PowerShell的下一步：安装PowerShell 7与模块生态

到了这一步，你应该已经理解了PowerShell的基础操作和避坑方法。接下来真正拉开人与人差距的，是模块化能力。PowerShell的模块库（PowerShell Gallery）里放着几万个现成模块，覆盖Azure云管理、Exchange、SQL Server、Docker、Kubernetes、网络安全等方方面面。安装一个模块，你就相当于给PowerShell扩展了一整套命令。

常用的安装命令：

# 安装Docker相关模块 Install-Module -Name DockerMSFTProvider -Force # 安装获取系统信息的模块 Install-Module -Name PSWindowsUpdate -Force # 查看已安装模块 Get-Module -ListAvailable

我强烈建议普通用户至少学会安装PowerShell 7，并配置Windows Terminal。因为它解决了很多5.1时代的糟心问题：乱码、性能慢、语法糖少、跨平台不友好。从5.1升级到7，你还没有抛弃任何重要东西，反而解锁了很多新功能。比如三元运算符a ? b : c、管道链操作&&、并行ForEach-Object -Parallel等，都能让脚本效率大幅提升。

举个例子，在PowerShell 7里并行处理多个任务：

1..10 | ForEach-Object -Parallel { Start-Sleep -Seconds 1 "Task $_ done" } -ThrottleLimit 5

这在5.1里要么写复杂的Runspace，要么逐个执行。有了并行能力，很多耗时脚本都能加速数倍。

最后再分享一个我的个人习惯：在PowerShell里始终开着一个"日志脚本"，把每次执行过的关键命令追加到文件里。这样即使脚本临时出错，也有迹可循，复查时非常省力。PowerShell这条路一旦走通，受益的绝不仅仅是某个单独任务，而是你整个Windows使用方式都会升级。