这次我们来看一个非常实用的方案：不用装 VMware、不用搞双系统、不用重新给硬盘分区，直接在 Windows 上安装和使用 Linux。这个方案就是微软官方的 WSL（Windows Subsystem for Linux，也就是常说的 Windows 子系统）。
WSL 对很多开发者来说并不是一个新词，但如果你过去只听过名字、没真正动手装过，这篇文章就是给你准备的。它最大的价值在于：你不需要维护一台虚拟机的完整开销，不需要学习 ESXi、Hyper-V 那一套复杂管理，也能在 Windows 环境里直接敲 Linux 命令、跑 Linux 软件、部署 Docker 服务、写跨平台脚本。相比传统虚拟机，它启动更快、资源占用更低、和 Windows 文件系统互通更自然，而且支持 API 式的命令行操作，非常适合做本地开发、测试环境搭建和脚本练习。
这篇文章会从零开始，先讲清楚 WSL 和虚拟机的本质区别，再给出核心能力速览和适用边界；接着完整演示 Windows 环境准备、WSL 安装启动、Ubuntu 发行版部署；然后做功能验证，包括文件互访、软件安装、systemd 服务、Docker 和常见服务搭建；最后补充资源占用观察、常见问题排查方法和一套最佳实践。如果你正在 Windows 上折腾 Linux、想摆脱虚拟机卡顿，或者准备接入 WSL 做自动化开发环境，这篇可以直接收藏。
1. 核心能力速览
先把 WSL 的核心规格放在最前面，方便你快速判断它是否适合自己。
| 能力项 | 说明 |
|---|---|
| 项目类型 | 微软官方提供的 Windows 子系统，用于在 Windows 上运行 Linux 环境 |
| 主要功能 | Linux 命令行、文件系统访问、系统服务、Docker 容器、GUI 程序、GPU 加速推理 |
| 与传统虚拟机的关系 | WSL 2 使用轻量虚拟化技术，但不需要像常规虚拟机那样完整安装和管理系统 |
| 支持平台 | Windows 10、Windows 11，较新版本内置wsl命令 |
| 启动方式 | 命令行启动，可在 Windows Terminal 中直接打开 |
| 显存/内存占用 | 内存按需占用，可通过.wslconfig限制；显存取决于运行的程序 |
| 是否支持 API | 支持命令行调用，可被脚本、CI/CD、开发工具集成 |
| 是否支持批量任务 | 支持，可在同一 WSL 系统内并行或顺序执行脚本任务 |
| 是否支持 CPU 推理 | 支持，WSL 2 环境内可直接运行基于 CPU 的模型和任务 |
| 适合场景 | Linux 命令练习、前后端开发、Docker 部署、运维脚本测试、AI 本地推理开发 |
需要注意一点：WSL 2 在实现上确实使用了虚拟化平台（Virtual Machine Platform），但它和“用虚拟机软件装一个完整 Linux”是两种完全不同的使用体验。前者是 Windows 系统级集成的 Linux 环境，后者是完整独立的客户机系统。所以标题说的“不用虚拟机”，准确的表述是：不需要像 VMware Workstation 或 VirtualBox 那样手动创建虚拟机、分配内存、安装内核、装桌面环境。WSL 把这些步骤全部简化掉了。
2. 适用场景与使用边界
WSL 不是万能的，先想清楚你要用它做什么，能避免很多后续折腾。
2.1 适合谁
第一类用户是后端开发者和运维工程师。平时需要写 Shell 脚本、操作 Linux 命令、调试 Nginx、Redis、Nacos、Elasticsearch、Docker Compose 这类服务，但公司电脑又是 Windows，用 WSL 可以大幅减少在 Windows 和 Linux 之间来回切换的成本。
第二类用户是学生和刚入门 Linux 的人。传统的 Windows 下装 Linux 虚拟机往往要经历下载镜像、分配内存、安装系统、配置网络这一整套流程，WSL 则基本是“一条命令装完”。对入门者来说，少踩一个坑就多一分继续学下去的动力。
第三类用户是 AI 和数据处理方向的开发者。WSL 2 在官方层面支持 NVIDIA CUDA 直通，很多开源模型、推理脚本在 WSL 里的表现和原生 Linux 非常接近。Windows 上跑不通的某些依赖，换个 WSL 环境往往就能解决。
2.2 能解决什么问题
能解决的最核心问题，是“开发环境和生产环境不一致”。很多商用服务器、云主机跑的都是 Linux，你在 Windows 上写完的脚本，可能在 Linux 上因为路径分隔符、文件权限、依赖库版本差异而无法运行。WSL 提供了一套和 Linux 高度一致的环境，相当于把“本地开发环境”和“服务器运行环境”拉到同一个维度。
另外，WSL 的文件访问能力很直接：Windows 的 C 盘、D 盘会自动挂载到 WSL 的/mnt/c、/mnt/d，反过来你也能在 Windows 资源管理器里直接通过\\wsl$\Ubuntu访问 Linux 文件系统。这种双向访问比传统虚拟机的共享文件夹复制粘贴方便得多。
2.3 不适合什么场景
WSL 不适合需要完整图形桌面体验的场景，比如你想跑一个完整 Ubuntu 桌面环境做日常办公，WSLg 虽然能打开个别 GUI 程序，但和完整桌面系统相比仍有差距。
WSL 也不适合对底层硬件有极端要求的场景，比如需要直接读写 U 盘、调用 USB 加密狗、做内核模块级驱动开发。WSL 2 在硬件直通层面比传统虚拟机更受限，这些问题更适合用真实 Linux 主机或专业虚拟机方案。
此外，WSL 的文件 IO 性能有特殊性。如果你的项目文件放在 Windows 文件系统（比如/mnt/c下）并且频繁做大量读写，性能会明显慢于放在 Linux 原生文件系统（比如~/project）里。这个细节后面会重点说明。
2.4 版权、隐私与安全边界
使用 WSL 时，你仍然要遵守 Windows 系统许可、软件许可证以及各 Linux 发行版的许可条款。在企业环境使用 WSL 做开发时，要先确认公司网络安全规范是否允许启用虚拟化平台。尤其是当你在 WSL 里部署 Docker、运行数据库或者 AI 模型服务时，要确保数据来源合法、模型授权清晰，不要将未授权的数据、版权素材注入到本地或外部服务中。同时，WSL 环境默认以当前 Windows 用户身份运行，不要随意将 SSH 私钥、数据库密码、云平台凭证等敏感信息长期明文保存在 Linux 环境里。
3. 环境准备与前置条件
在开始安装之前，先检查一遍你的 Windows 环境是否满足 WSL 的基本要求。
3.1 操作系统版本要求
WSL 已经内置在较新的 Windows 10 和 Windows 11 中。最简单的判断方法是打开 PowerShell 或 CMD，输入wsl --version。如果系统能正常返回 WSL 版本信息，说明当前 Windows 已经自带 WSL；如果提示“wsl 不是内部或外部命令”，说明系统版本较旧，需要先升级系统，或者手动启用相关 Windows 功能。
一个常见情况是：Windows 10 的较老版本（比如 1903、1909）默认只支持 WSL 1，需要手动开启“适用于 Linux 的 Windows 子系统”功能。Windows 11 和 Windows 10 较新版本则直接支持 WSL 2，并且可以通过wsl --install一条命令安装。
3.2 开启虚拟化支持
WSL 2 依赖 Windows 虚拟化平台，所以你的 CPU 必须支持虚拟化，并且 BIOS 中已经开启。验证方法是在 Windows 的“任务管理器 -> 性能 -> CPU”中查看“虚拟化”一栏是否为“已启用”。如果显示“已禁用”，需要重启电脑进入 BIOS，找到 Intel VT-x 或 AMD-V 相关选项并打开。
这一步是 WSL 2 能否正常启动的关键。遇到启动报错时，不要急着重装，先检查虚拟化是否真的开启。
3.3 磁盘空间与网络环境
WSL 安装的 Linux 发行版会占用磁盘空间。一个最小的 Ubuntu 环境大约需要几个 GB 空间，再加上后续安装 Docker、开发依赖、模型文件，建议预留 20GB 以上空间。WSL 系统可以通过wsl --export和wsl --import迁移到其他盘，这一点在处理系统盘不够用时非常有用。
网络方面，从微软商店或命令行下载发行版需要能访问微软相关服务。如果你所在网络受限，可以改为离线方式：在微软官网手动下载 Linux 发行版.appx或.tar.gz文件，再用wsl --import导入运行。这部分我们放到安装章节展开。
3.4 提前了解 WSL 1 和 WSL 2 的区别
WSL 有两个大版本，理解它们之间的差异有助于你选择正确的使用方案。
| 对比项 | WSL 1 | WSL 2 |
|---|---|---|
| 系统调用方式 | 翻译层，不虚拟化 | 轻量级虚拟机，真实 Linux 内核 |
| Linux 内核兼容性 | 兼容性一般 | 兼容性高 |
| 启动速度 | 快 | 快，但首次启动略慢 |
| 内存占用 | 较低 | 按负载增长 |
| 文件 IO 性能 | 在 Windows 文件系统上表现更好 | 在 Linux 原生文件系统上更强 |
| Docker 支持 | 支持有限 | 完整支持 |
| 需要虚拟化功能 | 否 | 是 |
更稳妥的判断是：日常命令操作、脚本练习、网络工具用 WSL 1 也够用；但如果你要跑 Docker、编译 Linux 原生软件、调试 Kubernetes 集群或者做 AI 推理，直接选 WSL 2。现在绝大多数新安装场景都默认使用 WSL 2。
4. 安装部署与启动方式
下面进入实际操作环节。这里给出两种安装方式：推荐的新版一键安装，以及兼容旧系统的传统安装方法。
4.1 方式一：新版一键安装
如果你使用的是 Windows 11，或较新版本的 Windows 10，直接在 PowerShell 或 CMD 中运行：
wsl --install这条命令会做四件事：启用“适用于 Linux 的 Windows 子系统”功能、启用“虚拟机平台”功能、下载并安装 WSL 内核、安装默认的 Ubuntu 发行版。
安装完成后，系统大概率会提示重启电脑。重启后第一次运行 WSL，会让你设置 Linux 用户名和密码。这一步完成之后，你就已经进入了一个真实的 Ubuntu 环境。
如果执行wsl --install时提示“无法使用该命令”，说明你的系统版本太老，请直接使用下面的方式二。
4.2 方式二：传统安装方式
老版本 Windows 或企业定制版系统，可以手动开启两个 Windows 功能：
- 控制面板 -> 程序和功能 -> 启用或关闭 Windows 功能。
- 勾选“适用于 Linux 的 Windows 子系统”。
- 勾选“虚拟机平台”。
然后用管理员身份打开 PowerShell，继续执行内核更新和默认版本设置。
# 安装 WSL 内核 wsl --update # 设置默认版本为 WSL 2 wsl --set-default-version 2之后安装具体发行版：
# 查看可安装的发行版列表 wsl --list --online # 安装指定发行版，例如 Ubuntu 22.04 wsl --install -d Ubuntu-22.04如果你希望安装其他发行版，也可以通过wsl --install -d Debian、wsl --install -d kali-linux等方式安装。除了常见的 Ubuntu、Debian、openSUSE、Kali Linux、AlmaLinux 等，社区里也有在 WSL 中手动导入国产发行版镜像的做法，比如 deepin 这类桌面发行版，可以通过离线 tar 包导入，但默认不在商店一键列表里。
4.3 离线导入方式
如果你的网络无法直接访问微软商店或 WSL 在线源，可以采用离线导入：
- 在一台可以访问外网的电脑或官方镜像站点下载 Ubuntu WSL 镜像。
- 将
.tar.gz文件拷贝到目标电脑。 - 在目标电脑执行导入命令。
# 创建存放 WSL 系统的目录 mkdir D:\WSL\Ubuntu # 将 tar 文件导入为 WSL 发行版 wsl --import Ubuntu D:\WSL\Ubuntu D:\Downloads\ubuntu.tar.gz --version 2导入完成之后，用wsl -d Ubuntu进入系统。注意：通过wsl --import导入的发行版默认使用 root 登录，后续需要自己创建普通用户。从商店安装的发行版则会在第一次启动时引导创建用户。
4.4 启动与外部访问
WSL 安装完成后，可以通过多种方式启动：
# 启动默认发行版 wsl # 启动指定发行版 wsl -d Ubuntu-22.04 # 以指定用户启动 wsl -d Ubuntu-22.04 -u root # 退出 WSL exit如果你安装了 Windows Terminal，推荐把它和 WSL 一起使用。Windows Terminal 可以同时打开 CMD、PowerShell、WSL 多个标签页，并且支持自定义启动目录、主题颜色和快捷键，体验比系统自带的控制台好很多。
从技术角度看，你可以直接把 WSL 理解成一个命令行级别的集成服务，脚本、CI 工具、VS Code 都可以直接调用它。这种“可编程、可脚本化、可自动化”的接口能力，是它和普通虚拟机最大的风格差异。
5. 功能测试与效果验证
安装完成之后，建议按下面几个维度做一轮功能验证，确保环境真的能干活。
5.1 查看 WSL 版本和 Linux 基本信息
启动 WSL 后，依次执行以下命令：
# 查看当前登录用户 whoami # 查看 Linux 内核版本 uname -a # 查看发行版信息 cat /etc/os-release # 查看磁盘空间 df -h预期输出中，uname -a会显示 WSL 内核信息，/etc/os-release会显示你安装的发行版名称和版本号。如果这些命令能正常返回，说明 WSL 的基础调用链路没有问题。
在 Windows PowerShell 里，可以用另一条命令确认 VERSION 状态：
wsl -l -v输出中会看到每个发行版的名称，以及 VERSION 是 1 还是 2。建议全部统一为 2，这样 Docker 和 systemd 支持最完整。
5.2 测试 Windows 与 Linux 文件互访
这是 WSL 最有体验感的功能之一。在 WSL 命令行中输入：
# 查看 Windows 的 C 盘挂载位置 ls /mnt/c # 从 Linux 访问 Windows 桌面目录 ls /mnt/c/Users/你的用户名/Desktop反过来，在 Windows 资源管理器的地址栏输入\\wsl$\Ubuntu-22.04\home\你的用户名，可以直接用 Windows 图形界面访问 Linux 系统内的文件。
这里有一个值得重点记住的性能建议：WSL 2 在 Linux 原生文件系统（比如/home/用户名/）上做文件操作远比在/mnt/c上快。所以如果要跑编译、装依赖、跑 Docker 构建，请把工作目录放在 Linux 侧，不要放在/mnt/c下。
5.3 安装软件与包管理测试
WSL 中的 Ubuntu 可以使用apt安装软件，这是验证环境和生产 Linux 是否一致的核心步骤。
# 更新软件源信息 sudo apt update # 升级已安装软件包 sudo apt upgrade -y # 安装常用工具 sudo apt install -y git curl wget vim net-tools安装完成后，运行git --version、curl --version验证。能正常返回版本号，说明软件包管理器、软件源、依赖库都正常工作。这一步如果不做，后续跑任何服务都可能被各种依赖问题卡住。
5.4 使用 systemd 管理系统服务
WSL 2 在较新版本中默认启用 systemd，这意味着你可以使用systemctl管理服务，和真实 Linux 服务器保持一致。检查方法：
# 检查 systemd 是否运行 ps -p 1 -o comm=如果输出为systemd，说明 systemd 正常工作。如果输出为init，可能需要在/etc/wsl.conf中手动启用，然后执行wsl --shutdown重启 WSL。
之后就可以像真实 Linux 一样操作服务：
sudo systemctl status cron sudo systemctl enable cron sudo systemctl start cron5.5 测试 GUI 程序和 GPU 支持
如果你的 WSL 版本支持 WSLg，可以直接在 WSL 里启动 Linux 图形程序，窗口会显示在 Windows 桌面上。比如：
# 安装一个简单的图形编辑器 sudo apt install -y gedit # 启动 GUI 程序 gedit如果你要做 AI 或 CUDA 相关开发，可以验证 WSL 内是否能看到 GPU：
nvidia-smi如果能正常列出显卡信息，说明 GPU 驱动已经和 WSL 打通。这里需要强调：显存和 GPU 占用由具体运行的程序决定，不同模型、不同推理框架差异很大，建议以本机实测为准。WSL 2 对 CUDA 的支持属于官方能力范围，但驱动版本必须和 Windows 驱动匹配。
6. 在 WSL 中搭建开发服务与批量任务
WSL 不只是一个“敲命令的玩具”。实际开发中，很多服务可以直接丢进 WSL 里跑，通过端口localhost映射到 Windows 访问。
6.1 启动 Redis
安装 Redis 非常简单：
sudo apt install -y redis-server sudo systemctl start redis验证是否正常：
redis-cli ping如果输出PONG，说明 Redis 正常运行。Windows 侧的浏览器或客户端可以直接访问localhost:6379。
6.2 启动 Elasticsearch
搜索词里频繁出现“windows启动elasticsearch”，就是因为很多人不想在 Windows 上配 Java 环境和各种服务参数。
sudo apt install -y openjdk-17-jdk下载 Elasticsearch 压缩包后放到~/es/目录，执行：
tar -zxvf elasticsearch-*.tar.gz cd elasticsearch-*/ bin/elasticsearch启动后 Windows 浏览器访问localhost:9200就能看到 JSON 返回信息。要注意 Elasticsearch 不允许 root 用户直接启动，需要新建一个专门用户来跑，这正好是熟悉 Linux 用户和权限管理的好机会。
sudo useradd -m es_user sudo chown -R es_user:es_user ~/es su - es_user ~/es/elasticsearch-*/bin/elasticsearch6.3 使用 Docker 部署容器环境
WSL 2 支持完整 Docker，有两条路线。一是安装 Docker Desktop，并使其使用 WSL 2 backend；二是在 WSL 内部直接安装 Docker Engine。对于更偏 Linux 原生体验的用户，推荐后者。
sudo apt update sudo apt install -y docker.io sudo systemctl start docker sudo systemctl enable docker # 验证 sudo docker run hello-world之后你就可以在 WSL 里直接使用 Docker 命令，比如跑 Nginx、MySQL、Nacos 等中间件。
这里还要提示一下：Docker 拉取镜像速度受网络环境影响，遇到超时问题可以先排查镜像源配置和网络条件，而不是反复重装 Docker。
6.4 批量任务脚本示例
WSL 天然支持 Bash 脚本，可以把它作为批量任务的执行器。比如下面的脚本用于批量压缩指定目录下的文件：
#!/bin/bash input_dir=/home/用户名/inputs output_dir=/home/用户名/outputs mkdir -p "$output_dir" for file in "$input_dir"/*.log; do if [ -f "$file" ]; then base_name=$(basename "$file") tar -czf "$output_dir/${base_name}.tar.gz" "$file" fi done echo "批量压缩完成，共处理 $(ls "$input_dir"/*.log | wc -l) 个文件"保存为batch_compress.sh，执行：
chmod +x batch_compress.sh ./batch_compress.sh这种任务如果放在传统虚拟机里，你需要开机、等系统启动、手动拷贝文件，WSL 则可以直接从 Windows Terminal 启动并快速执行。配合 Windows 任务计划程序，你甚至可以在固定时间自动调用wsl执行 Linux 脚本。
6.5 开发工具链与 AI CLI 工具
现在的很多 AI 开发工具、代码生成 CLI 工具，都优先支持 Linux 环境。在 WSL 里可以直接安装和运行这类命令行工具，比如 Node.js、Python、Go 等语言环境，再安装 Claude Code、Codex 等工具时，环境兼容性问题会少很多。
# 安装 Node.js 18 的常见方式 curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash - sudo apt install -y nodejs # 安装 Python 相关工具 sudo apt install -y python3 python3-pip当然，如果你要用 Windows 桌面版的 Codex 应用，那就直接使用 Windows 原生版本即可，并不需要先装 WSL。WSL 更适合的是命令行工具和自动化脚本场景。
7. 资源占用与性能观察
很多人关心 WSL 到底占多少内存、CPU 占用为什么高，这里给出一个务实的观察方法。
7.1 内存占用观察
WSL 2 的内存是动态分配的。你可以打开 Windows 任务管理器，找到vmmem进程，它就是 WSL 2 虚拟机的进程。当你在 WSL 里编译、运行 Docker、启动数据库时，vmmem的内存会明显上升，这属于正常现象。
为了避免 WSL 吃掉整机内存，可以在 Windows 用户目录下创建一个.wslconfig文件，内容示例：
[wsl2] memory=4GB processors=2 swap=2GB localhostForwarding=true保存后执行wsl --shutdown，再重新进入 WSL 生效。这里的memory=4GB可以根据你的实际物理内存调整。如果机器有 32GB 内存，也可以设置成8GB。
7.2 WSL 1 与 WSL 2 的性能差异
从实际观察来看，WSL 2 在 Linux 原生文件系统上运行时，编译速度和 Docker 构建速度都很接近真实 Linux。但如果你把项目放在/mnt/c或/mnt/d这类 Windows 挂载盘上，反复读写时性能会明显下降。这是因为跨文件系统操作存在额外的转换开销。
所以建议形成一套固定的目录习惯：代码和项目放在 WSL 内部，比如/home/用户名/projects/；需要和 Windows 交互的文件再放到/mnt/c下。
7.3 如何降低资源占用
如果你同时跑多个 WSL 发行版，可以通过wsl --shutdown停止所有发行版，而不是一个一个退出。在需要再次使用时，输入wsl会自动启动。
如果想观察 WSL 内部资源情况，在 Linux 里使用：
free -h topfree -h可以查看内存和 swap 使用情况，top可以查看 CPU 和内存占用最高的进程。判断是否异常，关键是看有没有进程长期占满 CPU 或者内存持续不释放，而不是看偶尔的瞬时高峰。
8. 常见问题与排查方法
WSL 安装和使用过程中，很多问题都有固定的排查路径。这里整理一份常见问题清单。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
wsl命令不存在 | Windows 版本过旧或功能未启用 | 查看系统版本，检查 Windows 功能 | 升级系统，手动启用 WSL 功能 |
| 启动时提示“适用于 Linux 的 Windows 子系统必须更新到最新版本才能继续” | WSL 内核版本过旧 | 在 PowerShell 执行wsl --version | 执行wsl --update更新内核 |
安装后wsl -l -v没有列出发行版 | 未安装任何 Linux 发行版 | 执行wsl --list --online查看可用列表 | 执行wsl --install -d Ubuntu-22.04安装发行版 |
| WSL 2 启动失败，提示虚拟化未开启 | BIOS 中 Intel VT-x/AMD-V 未开启 | 任务管理器查看“虚拟化”状态 | 重启进入 BIOS 开启虚拟化 |
vmmem内存占用过高 | WSL 2 动态分配内存 | 任务管理器查看vmmem | 创建.wslconfig限制内存上限 |
| 报错“无法终止虚拟机进程”或端口冲突 | 部分服务占用端口，或 WSL 状态异常 | 检查 80/443 等常用端口 | 执行wsl --shutdown后重启 |
从/mnt/c访问文件很慢 | 跨文件系统读写开销大 | 检查项目路径 | 将项目移动到 Linux 原生文件系统 |
| Linux 系统无法安装 Docker | 发行版未启用 systemd 或内核版本过旧 | 执行ps -p 1 -o comm= | 启用 systemd，升级 WSL 内核 |
| 下载发行版超时或失败 | 网络环境限制 | 更换网络或使用离线导入 | 使用wsl --import导入 tar 包 |
| 启动 GUI 程序时提示无显示 | WSLg 未启用或版本过旧 | 执行echo $DISPLAY | 升级 WSL 到最新版本 |
除了上面这些，再重点强调一个坑：修改了/etc/wsl.conf或.wslconfig之后，很多配置不会立即生效。一定要执行wsl --shutdown，然后重新进入 WSL。如果你直接用exit退出再进，WSL 虚拟机可能还保留在内存中，配置变化根本不会加载。
9. 最佳实践与使用建议
9.1 第一次使用先做最小验证
首次装好 WSL 后，不要急着安装各种服务。先完成一套最小验证：执行uname -a查看内核，使用apt update更新软件源，在/mnt/c和 Linux 主目录之间做一次文件读写测试。这样能快速确认网络、磁盘和文件互访能力，避免后面出了问题分不清是系统问题还是服务配置问题。
9.2 项目文件统一放在 Linux 侧
所有代码项目、Docker 构建目录、Python 虚拟环境都放在 Linux 原生文件系统下。Windows 盘符下的文件只作为输入、输出和交换场景使用。这样可以最大化 WSL 2 的性能。
9.3 使用多发行版做环境隔离
WSL 支持同时安装多个 Linux 发行版。你可以把 Docker 环境放在 Ubuntu，把 Python 机器学习环境放在 Debian，把安全测试工具放在 Kali Linux。不同发行版之间通过wsl -d切换，互不干扰。
9.4 建立备份和迁移习惯
在折腾重要配置之前，先做一次导出：
wsl --export Ubuntu-22.04 D:\backup\ubuntu-22.04.tar需要恢复时使用导入命令。这样即使系统环境出了问题，也能快速回退到可用状态。
9.5 注意合法授权与安全边界
使用 WSL 时要注意几个边界：第一，登录凭据、密钥、云平台 token 不要直接明文存放在 Linux 主目录中；第二，如果 WSL 中部署的服务面向局域网或公网，要确认服务本身的安全配置，不要暴露带默认口令的数据库和中间件；第三，使用 AI 模型、声音克隆、图像生成等能力时，必须确认输入素材已获得合法授权，尤其涉及人脸、声音、品牌内容时必须严格合规；第四，企业环境中启用虚拟化平台和安装 Linux 子系统前，先确认是否符合公司信息安全规范。
从工具属性看，WSL 只是提供了一个 Linux 兼容运行环境，它不会自动替你做环境隔离和数据防护，这些最终还是要靠使用者自己管理。
10. 总结与下一步
WSL 最值得尝试的点，是它把 Linux 的使用门槛降到了很低：不需要维护虚拟机镜像，不需要给磁盘重新分区，一条命令就能装好，文件还能和 Windows 互通，Docker、GPU、systemd 这些关键能力也都在持续完善。
如果你第一次接触 WSL，建议先验证三件事：wsl -l -v确认版本为 2，/mnt/c目录能正常访问 Windows 文件，apt install能成功安装软件。这三步跑通，WSL 就已经具备日常开发环境的使用条件。最容易踩的坑其实有两个：一是项目文件放在 Windows 盘导致 IO 慢，二是修改配置文件后没有执行wsl --shutdown导致配置不生效。
下一步可以尝试的方向很多：把本地 Redis、MySQL、Nginx 都挪进 WSL，通过localhost端口映射给 Windows 服务调用；用 Docker Compose 搭建一套完整开发环境；或者在 WSL 里跑 AI 相关命令行工具，体验 Windows 下训练和推理工作流。如果你正在为“Windows 上要不要装虚拟机”纠结，可以先装一个 WSL 试试，“不用虚拟机”的体验远比想象中顺手，建议直接收藏备用。
