从 PowerShell 到 WSL：在 Windows 上获得更好的 CLI 开发体验

---

一、为什么需要使用 WSL（从真实痛点出发）

在 Windows 上使用 CLI（命令行工具）进行开发时，很多人会遇到以下问题。

---

1. 终端交互体验不理想

在 PowerShell 或 CMD 中：

• 光标编辑能力较弱（命令修改不够顺手）
• 快捷键与 Linux / macOS 不一致
• 一些 CLI 工具的交互体验不佳

对于频繁使用命令行的开发者来说，这会明显影响效率。

---

2. 命令生态不统一

很多开发教程默认基于 Linux 或 macOS，例如：

ls
grep
rm -rf

但在 PowerShell 中：

• 有些命令行为不同
• 有些命令需要替代写法
• 有些工具甚至不可用

这会导致一个常见问题：

有时候教程能跑，但自己跑不通

---

3. 中文乱码与编码问题

在 Windows 终端中，CLI 工具经常会出现：

• 输出乱码
• 编码不一致（GBK / UTF-8）
• 日志显示异常

---

4. 开发环境与服务器环境不一致

绝大多数后端服务运行在 Linux 上，但本地开发使用 Windows 时：

• 路径格式不同（\ vs /）
• 脚本兼容性问题
• 环境变量行为差异

这容易导致：

本地能跑，部署失败

---

小结

这些问题的本质是：

Windows 原生命令行更偏“系统工具”，而不是“开发优先设计”。

---

二、什么是 WSL（核心概念）

WSL，全称是：

Windows Subsystem for Linux

中文一般称为：

适用于 Linux 的 Windows 子系统

---

1. 本质是什么？

WSL 是 Windows 提供的一种能力：

在 Windows 系统中直接运行一个真实的 Linux 环境

你可以把它理解为：

你的电脑里同时运行了两个系统：

Windows（主系统）
Linux（WSL中的Ubuntu）

---

2. 和虚拟机的区别

很多人会把 WSL 和虚拟机（如 VMware、VirtualBox）混淆。

主要区别是：

• 不需要单独分配内存/磁盘
• 启动速度非常快
• 与 Windows 文件系统无缝集成
• 可以直接调用 Windows 工具

---

3. 文件系统关系

WSL 和 Windows 文件是互通的：

Windows 文件：

D:\project

在 WSL 中访问：

/mnt/d/project

---

4. 为什么对开发有价值？

WSL 的核心价值在于：

• 提供 Linux 原生 CLI
• 与服务器环境一致
• 支持主流开发工具链（Python、Node、Git、Docker等）

---

下面单独给出你提到部分的修改版。你可以把原文中的「三、如何安装和配置 WSL」「四、WSL 如何结合 VS Code」「五、如何在 VS Code 中使用 WSL」替换成下面内容。

---

三、如何安装、初始化和配置 WSL

前面已经说明，WSL 本身只是 Windows 提供的一种运行 Linux 的能力。真正用于开发时，还需要安装一个具体的 Linux 发行版，例如 Ubuntu。

---

1. 检查当前 WSL 状态

打开 PowerShell，执行：

wsl -l -v

这个命令用于查看当前已经安装的 WSL 发行版以及它们的运行状态。

如果你看到类似结果：

docker-desktop    Stopped    2

说明当前系统确实已经启用了 WSL，但这个 docker-desktop 是 Docker Desktop 自带的内部环境，主要用于 Docker 运行，并不适合作为日常开发环境。

正常用于开发时，应该安装类似 Ubuntu 这样的 Linux 发行版。

---

2. 安装 Ubuntu

在 PowerShell 中执行：

wsl --install -d Ubuntu

这个命令会自动下载并安装 Ubuntu。

安装过程中可能会显示下载进度，例如：

正在下载: Ubuntu
[        15.0%        ]

如果下载长时间停留不动，通常是网络问题。可以稍等一会儿，或者通过 Microsoft Store 手动搜索并安装 Ubuntu。

安装完成后，再次执行：

wsl -l -v

理想情况下会看到类似：

  NAME              STATE           VERSION
* Ubuntu           Running         2
  docker-desktop   Stopped         2

这里需要关注三点：

• Ubuntu 表示已经安装了用于开发的 Linux 发行版
• STATE 表示当前运行状态，Running 或 Stopped 都正常
• VERSION 为 2 表示使用 WSL 2

---

3. 初始化 Ubuntu

安装 Ubuntu 后，第一次启动时还不能直接使用。系统会进行初始化，并要求你创建 Linux 用户。

可以通过两种方式启动 Ubuntu。

方式一，在开始菜单中搜索：

Ubuntu

然后点击打开。

方式二，在 PowerShell 中输入：

wsl

第一次启动 Ubuntu 时，终端可能会显示类似内容：

Installing, this may take a few minutes...

稍等片刻后，会提示你创建用户名：

Enter new UNIX username:

这里输入的是 Linux 系统中的用户名，不一定要和 Windows 用户名一致。例如可以输入：

jack

然后系统会要求设置密码：

New password:
Retype new password:

这里要注意两点。

第一，输入密码时，终端不会显示任何字符，也不会显示星号。这是 Linux 终端的正常安全设计，不是卡住了。

第二，这个密码是 Ubuntu 里的用户密码，后面执行 sudo 命令时会用到。例如：

sudo apt update

设置完成后，如果看到类似提示符：

jack@DESKTOP:~$

说明 Ubuntu 已经初始化成功。

其中：

• jack 是你的 Ubuntu 用户名
• DESKTOP 是你的电脑主机名
• ~ 表示当前位于 Linux 用户主目录
• $ 表示当前是普通用户权限

此时你所在的位置通常是：

/home/jack

这相当于 Linux 中的用户个人目录，类似 Windows 里的：

C:\Users\你的用户名

可以执行下面命令确认当前路径：

pwd

输出可能是：

/home/jack

也可以查看当前目录中的文件：

ls

刚初始化完成时，这里可能没有太多内容，后续会出现 .bashrc、.profile、.cache 等配置文件。这些都是 Linux 用户目录中的正常配置文件。

---

4. 更新 Ubuntu 软件源

初始化完成后，建议先更新软件源。

在 Ubuntu 终端中执行：

sudo apt update

这个命令会从 Ubuntu 的软件源同步最新的软件包信息。

如果是第一次执行 sudo，系统会要求输入刚才设置的 Ubuntu 密码：

[sudo] password for jack:

同样，输入密码时不会显示字符，正常输入后按回车即可。

然后建议更新已安装的软件包：

sudo apt upgrade

如果系统询问是否继续：

Do you want to continue? [Y/n]

输入：

Y

然后按回车。

---

5. 安装基础开发工具

接下来安装一些常用开发工具：

sudo apt install git curl build-essential

这些工具的作用大致如下：

• git：用于代码版本管理
• curl：用于从网络请求或下载安装脚本
• build-essential：包含 C/C++ 编译相关基础工具，很多 Python、Node 依赖在安装时可能会用到

如果你主要写 Python，还可以安装：

sudo apt install python3 python3-pip python3-venv

安装完成后可以检查版本：

python3 --version
pip3 --version
git --version

需要注意，WSL 是独立的 Linux 环境。Windows 中原本安装的 Python、Node.js、Anaconda，并不会自动成为 WSL 里的开发工具。完整使用 WSL 开发时，建议在 WSL 中重新安装对应工具。

---

四、在 VS Code 中使用 WSL 进行开发

安装好 WSL 和 Ubuntu 后，下一步就是把它和 VS Code 结合起来。这样既可以保留 VS Code 图形化编辑器的便利，又可以使用 Ubuntu 的 Linux 命令行环境。

可以把这种方式理解为：

VS Code 的界面仍然在 Windows 上，但项目、终端、解释器和依赖可以运行在 WSL 的 Linux 环境中。

---

1. 安装 VS Code 的 WSL 扩展

打开 VS Code，进入扩展市场，搜索：

WSL

安装 Microsoft 官方发布的 WSL 扩展。

有些教程中会把它叫作 Remote - WSL。现在扩展市场里通常显示为 WSL，本质上是同一个功能：让 VS Code 可以连接到 Windows 中的 WSL 环境。

安装完成后，VS Code 就具备了打开 WSL 文件夹、运行 WSL 终端、使用 WSL 中解释器的能力。

---

2. 从 WSL 中打开 VS Code

推荐的方式是先进入 Ubuntu 终端，再用 code . 打开当前目录。

例如，先在 WSL 中创建一个专门存放项目的目录：

mkdir -p ~/projects
cd ~/projects

然后执行：

code .

这条命令的含义是：

使用 VS Code 打开当前目录。

这里的 . 表示当前目录。
如果当前目录是：

/home/jack/projects

那么 VS Code 打开的就是 WSL 中的这个目录。

成功后，VS Code 左下角会显示类似：

WSL: Ubuntu

这说明当前 VS Code 窗口已经连接到了 WSL。

---

3. 当前打开的到底是什么文件夹

这一点很容易让初学者困惑。

如果你在 WSL 终端中直接执行：

code .

而当前路径是：

/home/jack

那么 VS Code 打开的就是 Ubuntu 用户主目录。

你可能会在左侧资源管理器看到：

.cache
.bashrc
.profile
.vscode-server

这些不是你的项目文件，而是 Linux 用户目录中的配置文件。

所以正确使用方式是：

先 cd 到项目目录，再执行 code .

例如：

cd ~/projects/my-project
code .

这样 VS Code 打开的才是你的项目。

---

4. 推荐把项目放在哪里

使用 WSL 时，有两类路径需要区分。

Windows 中的路径类似：

D:\my-project

在 WSL 中访问时，对应路径是：

/mnt/d/my-project

也就是说，Windows 的磁盘会被挂载到 WSL 的 /mnt 目录下。

但如果是长期开发的项目，更推荐放在 WSL 自己的 Linux 文件系统中，例如：

/home/jack/projects/my-project

也可以简写为：

~/projects/my-project

原因是：

• Linux 工具读写 Linux 文件系统性能更好
• 路径格式更统一
• Python、Node、Git 等工具兼容性更好
• 更接近真实 Linux 服务器环境

当然，如果项目暂时还在 Windows 的 D 盘，也可以先这样打开：

cd /mnt/d/my-project
code .

这种方式可以运行，但长期项目更建议迁移到：

~/projects

---

5. 在 VS Code 中使用 WSL 终端

当 VS Code 左下角显示：

WSL: Ubuntu

说明当前窗口已经处于 WSL 模式。

此时打开终端：

Terminal → New Terminal

新终端默认就是 Ubuntu 终端，而不是 PowerShell。

你可以在终端中执行：

pwd

如果输出类似：

/home/jack/projects/my-project

说明终端确实运行在 WSL 中。

再执行：

which python3
which git

可能会看到：

/usr/bin/python3
/usr/bin/git

这表示当前使用的是 Ubuntu 中的 Python 和 Git，而不是 Windows 中的工具。

---

6. 轻量用法：只把 VS Code 终端换成 Ubuntu

如果暂时不想把整个项目迁移到 WSL，也可以只把 VS Code 的终端从 PowerShell 切换成 Ubuntu。

操作路径是：

Terminal → Select Default Profile → Ubuntu (WSL)

之后再新建终端时，默认打开的就是 Ubuntu 终端。

这种方式适合只想改善 CLI 体验的情况，例如：

• 不想使用 PowerShell
• 想使用 Linux 风格命令
• 想减少中文乱码和命令兼容问题

但需要注意，这种方式和完整 WSL 开发不同。

轻量用法通常是：

项目仍然在 Windows
终端切换为 Ubuntu

完整 WSL 开发则是：

项目在 WSL
终端在 WSL
解释器在 WSL
依赖也在 WSL

如果只是日常执行一些 CLI 命令，轻量用法已经足够。
如果希望环境更稳定、更接近服务器，建议使用完整 WSL 开发模式。

---

7. Python 项目示例

假设要在 WSL 中创建一个 Python 项目，可以执行：

cd ~/projects
mkdir test-python
cd test-python
code .

然后在 VS Code 的 WSL 终端中创建虚拟环境：

python3 -m venv venv

激活虚拟环境：

source venv/bin/activate

激活成功后，终端前面通常会出现：

(venv)

例如：

(venv) jack@DESKTOP:~/projects/test-python$

然后安装依赖：

pip install requests

此时这个依赖会安装到当前项目的 WSL 虚拟环境中，而不是 Windows 的 Python 或 Anaconda 中。

---

8. 打开已有 Windows 项目的方式

如果原本项目在 Windows 的 D 盘，比如：

D:\MedExamEasy-main

可以在 WSL 中执行：

cd /mnt/d/MedExamEasy-main
code .

这样可以用 VS Code 的 WSL 模式打开这个项目。

但如果这个项目后续会长期维护，更推荐复制或迁移到 WSL 中，例如：

mkdir -p ~/projects
cp -r /mnt/d/MedExamEasy-main ~/projects/
cd ~/projects/MedExamEasy-main
code .

这样项目就真正位于 WSL 的 Linux 文件系统中，后续 Python、Node、Git 等工具的体验会更稳定。

---

下面是重写后的“总结部分”，风格更偏技术博客收尾，逻辑更完整、内容更有层次，你可以直接替换原来的总结。

---

五、总结

本文从一个非常实际的问题出发：

在 PowerShell 中使用 CLI 体验不佳

并围绕这一问题，逐步引入 WSL 作为解决方案，最终构建出一套在 Windows 上接近 Linux 的开发环境。

---

1. 本文核心结论

WSL 的价值并不只是“多了一个终端”，而是：

在 Windows 上获得一套完整、独立且接近生产环境的 Linux 开发环境

通过 WSL，可以解决以下几个核心问题：

• CLI 命令生态不统一（Linux vs Windows）
• PowerShell 交互体验不佳
• 中文编码和输出不稳定
• 本地环境与服务器环境不一致

---

2. 两种使用方式回顾

在实际使用中，WSL 并不是“只能一种用法”，而是可以按需求选择不同模式。

（1）轻量模式：仅替换终端

VS Code 打开 Windows 项目
终端切换为 Ubuntu（WSL）

这种方式的特点是：

• 上手成本低
• 不需要迁移项目
• 可以快速改善 CLI 使用体验

适合刚接触 WSL 或仅想替代 PowerShell 的用户。

---

（2）完整模式：WSL 开发环境（推荐）

项目在 WSL 文件系统
VS Code 连接 WSL
终端、解释器、依赖全部在 Linux 中

这种方式的特点是：

• 环境更加干净
• 工具链完全统一
• 与 Linux 服务器一致

更适合长期开发和实际项目使用。

---

3. 推荐的使用路径

对于刚接触 WSL 的用户，不需要一次性完成所有迁移，可以分阶段进行。

第一阶段：替换 CLI

• 在 VS Code 中使用 Ubuntu 终端
• 不再使用 PowerShell
• 解决命令不一致、交互体验差的问题

第二阶段：迁移开发环境

• 在 WSL 中安装 Python、Node.js、Git 等工具
• 使用 Linux 环境运行项目
• 减少环境冲突

第三阶段：完整迁移项目

• 将项目迁移到 WSL 文件系统（如 ~/projects）
• 使用 VS Code + WSL 作为主力开发方式
• 实现与服务器环境一致

---

4. 关于已有 Windows 环境的说明

很多用户在 Windows 中已经安装了：

• Python / Anaconda
• Node.js
• Git

需要明确的是：

WSL 是一个独立的 Linux 系统，这些工具不会自动在 WSL 中可用

因此，在完整使用 WSL 开发时，建议在 WSL 中重新安装一套开发环境，而不是混用 Windows 和 WSL 的工具。

这样可以避免：

• 路径混乱
• 版本冲突
• CLI 行为不一致

---

5. 最终效果

当完成 WSL 开发环境搭建后，你将获得：

• 统一的 Linux CLI 体验
• 更少的环境问题和兼容问题
• 与服务器一致的开发环境
• 更高的开发效率

---

6. 延伸方向

在掌握 WSL 基础之后，可以进一步扩展到：

• Python 项目结构与虚拟环境管理
• Node.js / 前端工程化开发
• Docker 与容器开发（WSL 下体验更好）
• Git 与 SSH 配置优化

这些内容都可以在 WSL 环境中获得更稳定的体验。

---

最后

如果你长期在 Windows 上进行开发，那么从 PowerShell 迁移到 WSL，并不是一次简单的工具替换，而是一次开发环境的升级。

这种升级不会立即带来功能上的巨大变化，但会在日常开发中持续减少摩擦，逐渐体现价值。