企业官网建设流程全解析

1. 从一次脚本迁移说起：为什么我要认真对比这两个命令行

前阵子帮一个朋友把他那台用了五六年的老机器做系统迁移，顺手整理了一下他平时用的自动化脚本。结果发现一个很典型的现象：他电脑里躺着几十个.bat文件，从清理临时目录到批量重命名照片，全是当年从各种论坛抄来的 CMD 脚本。这些脚本在旧机器上跑得好好的，换到新系统之后，有的直接报错，有的中文全变成乱码，还有几个涉及网络请求的干脆卡死不动。

我问他为什么不换成 PowerShell，他说了一句特别有代表性的话：“CMD 我熟啊，PowerShell 那些命令看着就头大。”

这句话其实点出了很多人对这两个工具的认知状态。CMD 是 Windows 从 DOS 时代一路带过来的老伙计，命令短、上手快、资料多；PowerShell 则是后来居上的“正规军”，面向对象、功能强大，但学习曲线明显更陡。问题在于，现在已经是 Windows 11 的时代了，很多新系统里的默认行为、编码规则、权限模型都变了，继续用老思路写 CMD 脚本，踩坑几乎是必然的。

这篇内容我想做的事情很明确：把 PowerShell 和 CMD 放在一起，从实际使用的角度做一次彻底对比。不是那种“CMD 是命令提示符，PowerShell 是脚本语言”的百科式介绍，而是围绕真实场景——脚本迁移、编码处理、命令链写法、开机自启、权限管理、外部程序调用——把两者的差异、各自的适用边界、以及迁移过程中最容易翻车的地方讲清楚。

如果你平时只是偶尔打开命令行敲两个命令，那这篇内容能帮你搞清楚什么时候该用哪个；如果你手上有大量历史 CMD 脚本需要维护或者迁移，那这篇内容基本可以当作一份避坑手册来用。我会尽量把每个结论背后的原因讲透，让你不只是知道“怎么做”，而是明白“为什么这么做”。

2. 本质差异：一个传字符串，一个传对象

要理解 PowerShell 和 CMD 的所有行为差异，得先抓住它们最根本的设计哲学区别。这个区别不理解透，后面所有的坑你都会踩得莫名其妙。

2.1 CMD 的世界里只有文本

CMD 的运作模式非常朴素：你输入一行字符串，它解析这行字符串，找到对应的可执行程序，把参数传过去，程序输出一堆文本，CMD 把这堆文本原样显示在窗口里。整个过程中，CMD 自己并不“理解”这些文本的含义，它只是个搬运工。

举个例子，你在 CMD 里执行tasklist，它会吐出一张进程列表。这张列表对人来说是可读的，但对 CMD 来说，它就是一堆字符。如果你想从里面筛选出某个进程，只能用findstr这种文本过滤工具去匹配字符串：

tasklist | findstr "chrome"

这行命令能工作，但它本质上是在做“文本匹配”，而不是“按属性筛选”。如果某个进程的名字里恰好包含 chrome 但并不是你要找的那个，它也会被匹配出来。这就是文本流的局限。

2.2 PowerShell 的世界里是结构化对象

PowerShell 的设计思路完全不同。它执行Get-Process的时候，返回的不是一堆文本，而是一组对象。每个对象都有属性：Name、Id、CPU、WorkingSet等等。你可以直接按属性筛选、排序、计算：

Get-Process | Where-Object { $_.CPU -gt 100 } | Sort-Object CPU -Descending

这行命令的含义是“找出 CPU 时间超过 100 秒的进程，按 CPU 降序排列”。注意，这里没有任何文本匹配的动作，全是基于对象属性的操作。这就是 PowerShell 强大的根源。

这个差异带来的直接后果是：CMD 里很多需要“解析文本”才能完成的任务，在 PowerShell 里变成了“访问属性”。前者脆弱、依赖输出格式，后者稳定、不依赖显示格式。微软官方文档里有一句话总结得很到位：PowerShell 的管道传递的是对象，CMD 的管道传递的是文本。

2.3 这个差异如何影响你的日常操作

理解了这个本质差异，很多现象就说得通了。比如为什么 PowerShell 里cd到某个目录后，ls出来的东西比 CMD 的dir信息更丰富？因为Get-ChildItem返回的是文件系统对象，每个对象自带几十个属性，而dir只是把这些属性格式化成文本给你看。

再比如，为什么 PowerShell 里执行外部程序（比如python、git）时，输出有时候会“卡住”或者显示不全？因为外部程序输出的是纯文本，PowerShell 需要把这些文本重新包装成对象才能继续处理，这个转换过程在某些情况下会出问题。这是后面要专门讲的一个大坑。

提示：判断一个命令是 PowerShell 原生命令还是外部程序，看它的名字。原生命令遵循“动词-名词”格式，比如Get-Process、Set-Location、Remove-Item；外部程序通常是单个单词或者带.exe后缀，比如python、git、ipconfig。

3. 命令语法对照：那些看起来一样却完全不同的命令

很多人从 CMD 转到 PowerShell 时，最容易被“看起来一样”的命令坑到。cd、dir、copy、del这些命令在 PowerShell 里也能用，但它们要么是别名，要么行为有微妙差异。下面这张表是我整理的高频命令对照，建议收藏。

3.1 别名是个甜蜜的陷阱

PowerShell 为了照顾从 CMD 过来的人，给很多原生命令设置了别名。cd是Set-Location的别名，dir是Get-ChildItem的别名，copy是Copy-Item的别名。这看起来很方便，但实际上是个陷阱。

因为别名只映射了命令名，没有映射参数。你在 CMD 里习惯的copy /y source dest，在 PowerShell 里用copy别名执行会直接报错，因为Copy-Item不认识/y这个参数。正确的写法是Copy-Item -Force source dest。

我个人的建议是：在写脚本的时候，永远用完整的原生命令名，不要用别名。别名是给交互式命令行用的，脚本里用别名会让代码可读性变差，而且容易在不同版本之间出问题。你可以用Get-Alias查看某个别名对应的真实命令：

Get-Alias cd Get-Alias dir

3.2 变量和环境变量的引用方式

这是新手最容易搞混的地方。CMD 里设置变量用set，引用用%：

set MY_PATH=C:\Users\test echo %MY_PATH%

PowerShell 里设置变量用$，引用也用$：

$MY_PATH = "C:\Users\test" Write-Output $MY_PATH

环境变量的差异更大。CMD 里环境变量和普通变量用同一套%语法；PowerShell 里环境变量有专门的前缀$env:：

$env:PATH $env:USERPROFILE

这个差异在写跨平台脚本时特别重要。如果你在 PowerShell 脚本里写了%USERPROFILE%，它不会被解析，只会被当成普通字符串输出。

3.3 命令链运算符的版本坑

CMD 里用&&表示“前一个命令成功才执行后一个”，用&表示“无条件依次执行”，用||表示“前一个失败才执行后一个”。

PowerShell 在 7.0 版本之前，只支持;（无条件依次执行），不支持&&和||。如果你在 Windows PowerShell 5.1（Windows 10/11 自带的版本）里写&&，会直接报语法错误。这是很多从 CMD 迁移过来的脚本翻车的重灾区。

从 PowerShell 7.0 开始，&&和||被正式支持了。所以如果你要用这两个运算符，要么升级到 PowerShell 7，要么用传统写法替代：

# PowerShell 5.1 中的替代写法 command1 if ($?) { command2 }

$?是 PowerShell 的内置变量，表示上一条命令是否成功。这个写法在 5.1 和 7.x 里都能用，兼容性最好。

4. 编码与乱码：中文用户绕不开的一道坎

中文 Windows 用户在使用命令行时，遇到乱码的概率极高。这个问题的根源在于代码页（Code Page）和字符编码的历史遗留问题。CMD 和 PowerShell 在这方面的表现差异很大，处理方式也完全不同。

4.1 CMD 的代码页机制

CMD 默认使用系统区域设置对应的代码页。简体中文 Windows 的默认代码页是 936（GBK）。当你执行chcp命令时，可以看到当前代码页：

chcp

输出会是活动代码页: 936。这意味着 CMD 默认用 GBK 编码来解读和显示文本。如果你用type命令查看一个 UTF-8 编码的文本文件，中文就会变成乱码。

解决办法是临时切换代码页到 65001（UTF-8）：

chcp 65001

但这里有个坑：切换代码页之后，某些老程序的输出会变得不正常，因为它们的输出是按 GBK 编码的，现在被当成 UTF-8 来解读了。所以chcp 65001不是万能药，它只是把乱码从一个地方转移到另一个地方。

4.2 PowerShell 的编码处理

PowerShell 的编码处理比 CMD 复杂，因为它涉及三个层面：控制台输入编码、控制台输出编码、以及文件读写编码。

在 Windows PowerShell 5.1 里，Get-Content默认按系统 ANSI 编码（中文系统就是 GBK）读取文件。如果你读一个 UTF-8 文件，需要显式指定编码：

Get-Content -Path "test.txt" -Encoding UTF8

在 PowerShell 7.x 里，默认编码变成了 UTF-8（无 BOM），这个改动让跨平台脚本友好了很多，但也带来了新的兼容性问题：如果你用 7.x 写了一个脚本，里面用Get-Content读 GBK 文件，不指定编码就会乱码。

输出方面，PowerShell 5.1 的控制台输出编码默认跟随系统代码页。你可以通过设置$OutputEncoding和[Console]::OutputEncoding来调整：

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

这两行是很多中文 PowerShell 脚本的标配，建议直接放在脚本开头。

4.3 一个真实的乱码排查案例

我之前遇到过一个场景：一个 CMD 脚本调用 Python 程序，Python 输出中文，CMD 显示乱码。排查过程是这样的：

第一步，确认 Python 脚本本身的编码。用python -c "import sys; print(sys.stdout.encoding)"查看 Python 认为的标准输出编码。结果是cp936，也就是 GBK。

第二步，确认 CMD 的代码页。chcp显示 936，也是 GBK。理论上应该匹配，为什么还乱码？

第三步，检查 Python 脚本文件本身的编码。用十六进制工具打开，发现文件是 UTF-8 编码，但脚本里没有声明编码。Python 3 默认按 UTF-8 读取源文件，但输出时用的是cp936，如果脚本里的中文字符串在转换过程中出了问题，就会乱码。

最终的解决方案是在 Python 脚本开头加上编码声明，并且在输出时显式指定编码：

# -*- coding: utf-8 -*- import sys import io sys.stdout = io.TextIOWrapper(sys.stdout.buffer, encoding='utf-8')

然后在 CMD 里先执行chcp 65001，再运行 Python 脚本。这样整条链路的编码就统一到 UTF-8 了。

这个案例说明一个道理：乱码问题从来不是单一环节的问题，而是整条链路上编码不一致导致的。CMD 和 PowerShell 只是链路中的一环，排查时要通盘考虑。

注意：chcp 65001在某些 Windows 版本上会导致命令行窗口的字体显示异常，尤其是使用点阵字体的时候。建议把控制台字体改成 TrueType 字体（比如 Consolas 或微软雅黑），显示效果会正常很多。

5. 脚本编写与执行策略：从 bat 到 ps1 的迁移

CMD 脚本以.bat或.cmd为扩展名，PowerShell 脚本以.ps1为扩展名。两者在语法、执行方式、权限模型上都有本质区别。这一章讲迁移过程中最关键的几个问题。

5.1 执行策略：PowerShell 的第一道门槛

很多第一次运行.ps1脚本的人都会遇到这个错误：

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

这是 PowerShell 的执行策略（Execution Policy）在起作用。默认情况下，Windows 客户端系统的执行策略是Restricted，禁止运行任何脚本。这个设计是为了防止恶意脚本自动执行。

查看当前执行策略：

Get-ExecutionPolicy

修改执行策略（需要管理员权限）：

Set-ExecutionPolicy RemoteSigned

RemoteSigned的含义是：本地编写的脚本可以直接运行，从网络下载的脚本需要有数字签名才能运行。这是微软推荐的平衡安全性和便利性的设置。

这里要特别提醒一点：网上有些教程会让你执行Set-ExecutionPolicy Bypass，这个设置会完全关闭脚本执行限制，安全性极低。我强烈不建议在日常使用的机器上这么做。如果只是临时运行某个脚本，可以用-ExecutionPolicy Bypass参数只对那一次执行生效：

powershell -ExecutionPolicy Bypass -File "script.ps1"

这样既运行了脚本，又不会永久改变系统设置。

5.2 从 bat 到 ps1 的语法转换

下面用一个实际例子来演示迁移过程。假设有一个 CMD 脚本，功能是清理指定目录下超过 30 天的临时文件：

@echo off set TEMP_DIR=C:\Temp forfiles /p %TEMP_DIR% /s /m *.* /d -30 /c "cmd /c del @path" echo 清理完成

对应的 PowerShell 版本：

$TEMP_DIR = "C:\Temp" $cutoff = (Get-Date).AddDays(-30) Get-ChildItem -Path $TEMP_DIR -Recurse -File | Where-Object { $_.LastWriteTime -lt $cutoff } | Remove-Item -Force Write-Output "清理完成"

对比一下就能看出差异。CMD 版本依赖forfiles这个外部工具，参数晦涩，日期计算用/d -30这种简写。PowerShell 版本用Get-Date做日期计算，用Where-Object做条件筛选，逻辑清晰得多，而且不依赖外部工具。

更重要的是，PowerShell 版本可以轻松扩展。比如你想加一个“只删除 .tmp 文件”的条件，只需要在Where-Object里加一个判断：

Get-ChildItem -Path $TEMP_DIR -Recurse -File | Where-Object { $_.LastWriteTime -lt $cutoff -and $_.Extension -eq ".tmp" } | Remove-Item -Force

CMD 版本要加这个条件，就得改forfiles的/m参数，而且不支持多个扩展名。

5.3 调用外部程序时的引号地狱

CMD 和 PowerShell 在调用外部程序时，引号的处理规则完全不同，这是迁移过程中最容易出问题的地方。

CMD 里，如果路径包含空格，用双引号包起来：

"C:\Program Files\MyApp\app.exe" "C:\My Documents\file.txt"

PowerShell 里，调用外部程序时，如果路径包含空格，需要用&调用运算符：

& "C:\Program Files\MyApp\app.exe" "C:\My Documents\file.txt"

如果不加&，PowerShell 会把带空格的路径当成字符串，而不是命令。这个坑我踩过不止一次。

更麻烦的是参数传递。PowerShell 在把参数传给外部程序时，会做一层解析，有时候会改变参数的原始形式。比如你想传一个包含引号的参数给外部程序，可能需要用反引号转义：

& "app.exe" "`"quoted argument`""

这种写法可读性极差，而且容易出错。我的经验是：如果外部程序的参数特别复杂，考虑用Start-Process配合参数数组：

$args = @("-input", "C:\My Documents\file.txt", "-output", "result.txt") Start-Process -FilePath "app.exe" -ArgumentList $args -Wait -NoNewWindow

-Wait表示等待程序执行完成，-NoNewWindow表示在当前窗口运行而不是弹新窗口。这两个参数在脚本自动化里非常常用。

6. 权限与提权：管理员身份的正确打开方式

Windows 的权限模型决定了有些操作必须以管理员身份执行。CMD 和 PowerShell 在提权方面的处理方式不同，理解这些差异能帮你避免很多“为什么命令执行失败”的困惑。

6.1 CMD 的提权方式

CMD 本身没有内置的提权机制。要以管理员身份运行 CMD，通常的做法是：在开始菜单搜索“cmd”，右键选择“以管理员身份运行”。或者在已经打开的 CMD 里，用runas命令启动一个新的提权进程：

runas /user:Administrator cmd

但runas需要输入管理员账户密码，而且启动的新窗口和当前窗口是独立的，环境变量不共享。这在脚本自动化里很不方便。

6.2 PowerShell 的提权方式

PowerShell 同样没有内置的“自我提权”命令，但可以通过Start-Process配合-Verb RunAs参数来启动一个提权的 PowerShell 进程：

Start-Process powershell -Verb RunAs -ArgumentList "-File `"C:\script.ps1`""

这行命令会弹出一个 UAC 确认框，用户确认后，会以管理员身份启动一个新的 PowerShell 进程来执行脚本。

这里有个重要的细节：提权后的进程是一个全新的进程，它不会继承当前进程的变量、函数、模块。所以如果你在脚本里定义了一些变量，提权后是用不了的。解决办法是把所有需要的东西都写在脚本文件里，通过-File参数传递。

6.3 判断当前是否具有管理员权限

在脚本里，经常需要判断当前是否以管理员身份运行。PowerShell 里可以用这个写法：

$isAdmin = ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) if (-not $isAdmin) { Write-Output "需要管理员权限" exit 1 }

CMD 里判断管理员权限比较麻烦，通常用net session命令的返回值来间接判断：

net session >nul 2>&1 if %errorlevel% neq 0 ( echo 需要管理员权限 exit /b 1 )

net session是一个需要管理员权限才能执行的命令，如果执行失败（errorlevel 非 0），说明当前不是管理员。

提示：在 Windows 11 上，UAC 的默认行为是“仅当应用尝试更改我的计算机时通知我”。这意味着即使你以管理员账户登录，普通进程也不会自动获得管理员权限。所以提权判断在脚本里是必须的。

7. 开机自启与后台运行：两种不同的实现路径

开机自启是很多自动化脚本的常见需求。CMD 和 PowerShell 脚本在实现自启时，思路和工具都不一样。

7.1 CMD 脚本的开机自启

CMD 脚本实现开机自启，最传统的方式是放到“启动”文件夹：

C:\Users\用户名\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

把.bat文件或者它的快捷方式放进去，登录时就会自动执行。这种方式简单直接，但有个缺点：脚本执行时会弹出一个命令行窗口，而且窗口不会自动关闭，除非脚本最后加了exit。

另一个方式是注册表：

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

在这个键下新建一个字符串值，数据指向脚本路径。这种方式和启动文件夹效果一样，但更隐蔽，适合不想让用户轻易发现的场景。

7.2 PowerShell 脚本的开机自启

PowerShell 脚本实现自启，思路类似，但因为执行策略的限制，不能直接把.ps1文件放到启动文件夹（会被执行策略拦截）。通常的做法是创建一个.bat或.cmd的启动器，在里面调用 PowerShell：

@echo off powershell -ExecutionPolicy Bypass -WindowStyle Hidden -File "C:\scripts\startup.ps1"

-WindowStyle Hidden参数让 PowerShell 窗口隐藏运行，不会弹出来打扰用户。这是实现“静默自启”的关键。

如果想让脚本在后台持续运行（比如定时任务），可以用计划任务（Task Scheduler）：

$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy Bypass -WindowStyle Hidden -File `"C:\scripts\monitor.ps1`"" $trigger = New-ScheduledTaskTrigger -AtLogOn Register-ScheduledTask -TaskName "MyMonitor" -Action $action -Trigger $trigger -RunLevel Highest

这段代码创建了一个登录时触发的计划任务，以最高权限运行 PowerShell 脚本。-RunLevel Highest表示以管理员权限运行，适合需要提权的脚本。

7.3 静默运行的一个实用技巧

如果你想让 CMD 脚本静默运行（不显示窗口），可以用 VBScript 包装：

Set WshShell = CreateObject("WScript.Shell") WshShell.Run "cmd /c C:\scripts\mytask.bat", 0, False

保存为.vbs文件，双击执行时不会显示任何窗口。Run方法的第二个参数0表示隐藏窗口，第三个参数False表示不等待脚本执行完成。

PowerShell 脚本的静默运行更简单，直接用-WindowStyle Hidden参数就行。但要注意，隐藏窗口后，脚本里的Write-Host输出就看不到了，调试时会很不方便。建议在开发阶段先用可见窗口运行，确认没问题后再改成隐藏。

8. 外部程序调用：Python、Git 等工具的集成

现代开发工作流里，命令行脚本经常需要调用外部程序，比如 Python、Git、Node.js。CMD 和 PowerShell 在这方面的表现差异很大，尤其是涉及输出捕获和错误处理的时候。

8.1 CMD 调用外部程序

CMD 调用外部程序很直接，直接写程序名就行：

python script.py git status

捕获输出用重定向：

python script.py > output.txt 2>&1

2>&1表示把标准错误也重定向到标准输出，这样错误信息也会被写入文件。

CMD 里判断外部程序是否执行成功，用%errorlevel%：

python script.py if %errorlevel% neq 0 ( echo 执行失败 )

8.2 PowerShell 调用外部程序

PowerShell 调用外部程序同样直接写程序名，但输出处理方式不同。默认情况下，外部程序的输出会被 PowerShell 逐行捕获为字符串数组：

$output = python script.py $output | ForEach-Object { Write-Output "行: $_" }

这里有个坑：如果外部程序输出大量数据，PowerShell 会先把所有输出缓存在内存里，然后再赋值给变量。如果输出量特别大（比如几百 MB），可能会导致内存占用飙升。解决办法是用管道直接处理，不要先赋值给变量：

python script.py | ForEach-Object { ... }

另一个坑是错误处理。PowerShell 默认不会把外部程序的非零退出码当成错误，$?变量在外部程序返回非零时会是$false，但不会抛出异常。要获取退出码，用$LASTEXITCODE：

python script.py if ($LASTEXITCODE -ne 0) { Write-Error "Python 脚本执行失败，退出码: $LASTEXITCODE" }

8.3 一个 Python 与 PowerShell 协作的实际案例

我之前做过一个数据处理的自动化流程：用 Python 做数据清洗，用 PowerShell 做文件调度和结果汇总。核心逻辑是这样的：

$dataDir = "C:\Data\incoming" $outputDir = "C:\Data\processed" Get-ChildItem -Path $dataDir -Filter "*.csv" | ForEach-Object { $inputFile = $_.FullName $outputFile = Join-Path $outputDir $_.Name python "C:\Scripts\clean_data.py" --input $inputFile --output $outputFile if ($LASTEXITCODE -eq 0) { Write-Output "处理成功: $($_.Name)" Move-Item -Path $inputFile -Destination "C:\Data\archive\$($_.Name)" } else { Write-Error "处理失败: $($_.Name)" } }

这个脚本展示了 PowerShell 在文件调度方面的优势：Get-ChildItem获取文件列表，ForEach-Object遍历，Join-Path拼接路径，Move-Item归档。这些操作如果用 CMD 写，需要大量for循环和字符串拼接，可读性和可维护性都差很多。

注意：在 PowerShell 里调用 Python 时，如果 Python 脚本输出中文，可能会遇到编码问题。建议在 Python 脚本里显式设置标准输出编码为 UTF-8，并且在 PowerShell 里设置[Console]::OutputEncoding = [System.Text.Encoding]::UTF8。

9. 常见故障排查：从报错信息反推问题根源

这一章整理几个高频故障场景，每个场景都给出完整的排查链路，方便你遇到类似问题时参考。

9.1 “无法将‘set-location’项识别为 cmdlet”

这个报错通常出现在你试图用cd命令切换到一个不存在的路径时。PowerShell 的报错信息有时候会让人困惑，因为它报的是Set-Location（cd的真实命令名），而不是cd。

排查步骤：

1. 确认路径是否存在：Test-Path "你的路径"
2. 确认路径里有没有特殊字符需要转义
3. 如果路径包含空格，用引号包起来：cd "C:\Program Files"
4. 如果是跨盘符切换，PowerShell 需要加-LiteralPath参数或者先切换到目标盘符

实际上，这个报错更常见的原因是路径拼写错误或者路径不存在。PowerShell 的报错信息不够直观，容易让人以为是命令本身的问题。

9.2 “安装了 Python 但 CMD 里找不到 python 命令”

这是环境变量配置问题。Python 安装时有一个选项叫“Add Python to PATH”，如果没勾选，安装程序不会把 Python 的安装目录加到系统 PATH 环境变量里。

排查步骤：

1. 在 CMD 里执行where python，看是否能找到
2. 如果找不到，手动检查 PATH：echo %PATH%
3. 找到 Python 安装目录（通常在C:\Users\用户名\AppData\Local\Programs\Python\Python3xx）
4. 把这个目录和它的Scripts子目录加到 PATH 里

在 PowerShell 里临时添加 PATH：

$env:PATH += ";C:\Users\用户名\AppData\Local\Programs\Python\Python311"

永久添加需要用系统设置或者setx命令：

setx PATH "%PATH%;C:\Python311" /M

/M表示修改系统级环境变量，需要管理员权限。不加/M则修改用户级环境变量。

9.3 “cmd 窗口闪退”

CMD 脚本双击运行时窗口一闪而过，通常是因为脚本执行完毕自动关闭了。解决办法是在脚本最后加pause：

@echo off echo 正在执行... rem 你的命令 pause

pause会显示“请按任意键继续...”，等待用户按键后才关闭窗口。这在调试阶段非常有用。

如果是 PowerShell 脚本闪退，可以在脚本最后加Read-Host：

Read-Host "按回车键退出"

9.4 “PowerShell 中的乱码如何处理”

前面已经详细讲过编码问题，这里补充一个快速排查流程：

这个表格基本覆盖了 90% 的乱码场景。遇到乱码时，按表格逐项排查，通常几分钟就能定位问题。

10. 选型建议：什么场景用 CMD，什么场景用 PowerShell

讲了这么多差异，最后回到一个实际问题：日常工作中到底该用哪个？

我的判断标准很简单：一次性、简单的系统操作，用 CMD；需要逻辑判断、数据处理、复杂流程的，用 PowerShell。

具体来说，以下场景适合 CMD：

• 快速查看 IP 配置（ipconfig）
• 测试网络连通性（ping、tracert）
• 简单的文件复制、移动、删除
• 执行单个外部程序并查看输出
• 在老旧的、只支持 CMD 的环境里工作

以下场景适合 PowerShell：

• 需要按条件筛选文件或进程
• 需要处理结构化数据（CSV、JSON、XML）
• 需要编写带逻辑判断和循环的脚本
• 需要调用 REST API 或处理网络请求
• 需要做批量操作和自动化调度
• 需要跨平台兼容（PowerShell 7 支持 Linux 和 macOS）

还有一个现实因素：微软已经把 PowerShell 作为 Windows 的主力命令行工具，新功能和新 API 都优先在 PowerShell 里支持。CMD 虽然还会长期存在（因为大量遗留脚本依赖它），但它的功能基本已经冻结了。从长远看，投入时间学习 PowerShell 的回报率明显更高。

不过我也不建议完全抛弃 CMD。有些场景下 CMD 确实更直接，比如你只是想快速看一下本机 IP，打开 CMD 敲ipconfig比打开 PowerShell 敲Get-NetIPAddress快得多。工具是拿来用的，不是拿来站队的。

我个人的习惯是：把 PowerShell 作为主力工作环境，配置好 profile，设置好编码，日常的脚本和自动化都用 PowerShell 写。遇到需要快速执行单个命令的场景，直接在 PowerShell 里敲，因为大部分 CMD 命令在 PowerShell 里也能用（通过别名或者直接调用外部程序）。只有在维护历史遗留的.bat脚本时，才会专门打开 CMD 去调试。

如果你正在考虑从 CMD 迁移到 PowerShell，我的建议是不要一次性全部迁移。先把最常用、最痛的那几个脚本迁移过来，跑通之后再逐步扩展。迁移过程中遇到问题，回头查一下这篇内容里的对照表和排查流程，大部分坑都能避开。