ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

WSL 玩转 Ubuntu 全指南:从安装到 Docker/CUDA 实战

2026/10/2 6:43:36 拓冰建站 浏览量
WSL 玩转 Ubuntu 全指南:从安装到 Docker/CUDA 实战 说实话这两年我在 Windows 上做开发几乎一大半时间都泡在 WSL 的 Ubuntu 里。从一开始只会装个 Ubuntu 子系统跑跑命令到后来把 Docker、PyTorch、CUDA、数据库全部搬进去中途踩过的坑基本能写一本小册子了。这篇全指南我就结合自己的实战经验从安装、配环境、日常使用到故障排查把 WSL 玩转 Ubuntu 的完整链路给你捋清楚。不管你是刚接触 Windows 子系统的小白还是已经在 Windows 上被各种环境问题折磨到想重装系统的老手这篇文章都很适合你。我会把每一步为什么这样做、遇到问题怎么排查都讲透尽量让你看完能直接照着操作。2. 为什么说 WSL 是你在 Windows 上使用 Linux 的最佳起点在开始装之前我想先说清楚一个核心问题你到底是需要 WSL还是需要一台虚拟机甚至直接改装双系统这个选择题做对了后面能少折腾好几天。2.1 三种方案的真实使用场景对比我身边有很多朋友一上来就装 VMware 虚拟机或者干脆把电脑搞成双系统。不能说这些方案不行但要看你实际想干什么。双系统适合你确定未来很长一段时间主要工作在 Linux 下不需要频繁切回 Windows。缺点很明显——两个系统不能同时跑切换要重启而且万一引导出问题修起来很麻烦。我自己曾经在双系统上吃过亏后来果断放弃了。虚拟机VMware / VirtualBox适合你想完整跑一个带图形界面的桌面环境测试一些 WSL 支持得不好的软件。缺点是资源开销大你给虚拟机的内存和 CPU 是实打实分出去的磁盘镜像动辄几十 GB启动也要等半天。WSL 2它本质上是一个轻量级虚拟机但集成了 Windows 的文件系统互操作和网络能力。你用起来几乎没有虚拟机的隔离感Windows 和 Linux 的文件可以互相访问端口可以直接互通启动终端的速度接近原生。这中间最关键的差异在于Windows 和 Linux 变成了同一个桌面环境里的“两个工具”而不是两个割裂的系统。如果你只是想做 Web 开发、Python 数据分析、跑跑深度学习模型、操作 Git 和 Docker那 WSL 2 完全够用而且它是目前综合体验最顺滑的方案。2.2 WSL 1 和 WSL 2 到底选哪个很多教程会直接让你装 WSL 2但我建议你理解一下两者的差别。WSL 1 是系统调用翻译层没有真正的 Linux 内核文件访问直接走 Windows 文件系统所以如果你经常要在 Windows 和 Linux 两侧读写文件WSL 1 在某些场景下反而更快。WSL 2 是真正的轻量级虚拟机自带完整的 Linux 内核兼容性更好——Docker、CUDA 这类需要内核特性的软件只能在 WSL 2 上跑。代价是跨文件系统访问性能变差了从 Linux 里读 Windows 桌面的文件会明显慢一截。我的建议很直接默认用 WSL 2。如果你只是偶尔需要跑几条命令不涉及 Docker 这类需要内核能力的软件并且特别在意 Windows 和 Linux 文件混用的速度再切回 WSL 1 也不迟。切换只需要一条命令wsl --set-version Ubuntu-22.04 1把最后的 1 改成 2 就是切回 WSL 2。2.3 硬件和系统版本的要求WSL 2 要求 Windows 10 的 2004 版本build 19041以上或者 Windows 11。CPU 需要支持虚拟化也就是 BIOS 里的 Intel VT-x 或 AMD-V 功能。大部分电脑默认是开着的但我见过不少机器连 Hyper-V 平台都没启用导致装完全套东西后 0x80370102 报错后面我会专门讲这个。内存方面WSL 2 默认最多占用你物理内存的 50%。如果你有 16GB 内存默认情况下 WSL 最多用 8GB可以通过.wslconfig文件调整后面细说。3. 安装 WSL 与 Ubuntu 子系统完整流程与常见报错排查现在来到实操环节。这部分我会把你从零带到能打开 Ubuntu 终端同时把最容易出问题的几个报错单独拎出来讲。3.1 一键安装与手动启用的两条路如果你用的是 Windows 10 21H2 或 Windows 11 之后的版本直接在管理员 PowerShell 里跑这行命令就能完成大部分安装wsl --install这条命令默认会安装 WSL 2同时给你装好 Ubuntu具体版本取决于当前默认发行版。装完会提示你重启重启后第一次启动 Ubuntu 会要求你设置用户名和密码。如果你的系统版本比较老或者想手动控制步骤可以走这个路线先用管理员 PowerShell 启用功能。dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart启用后重启再把 WSL 默认版本设为 2wsl --set-default-version 2最后在微软商店里搜索 Ubuntu 安装就行。3.2 把发行版装到 D 盘的正确姿势你在商店里直接点安装系统默认会把它塞进 C 盘。很多人 C 盘空间吃紧搜“wsl安装到d盘”也找不到靠谱答案其实核心只有两步。第一步在商店里安装好 Ubuntu 后先导出当前发行版为 tar 文件wsl --export Ubuntu-22.04 D:\wsl-backup\ubuntu2204.tar如果此时系统提示发行版正在运行先执行wsl --shutdown关掉它。第二步注销掉原来的发行版再导入到 D 盘wsl --unregister Ubuntu-22.04 wsl --import Ubuntu-22.04 D:\WSL\Ubuntu2204 D:\wsl-backup\ubuntu2204.tar导入完成后你会发现一个细节默认用户变成了 root网上很多教程没提这一步。你需要回到原有设置用管理员 PowerShell 运行ubuntu2204.exe config --default-user yourname其中yourname是你最初设置的用户名。这样等你用wsl ~进入子系统时就不再是 root 身份了。3.3 第一次启动后的初始化习惯第一次进 Ubuntu 终端我建议你按这个顺序做三件事先更新软件源和系统基础包sudo apt update sudo apt upgrade -y然后安装一组常用工具少了哪个后面都可能卡住sudo apt install -y build-essential git curl wget net-tools unzip zip最后配置默认 shell。如果你受够了 bash 的审美可以直接装 zshsudo apt install -y zsh chsh -s /usr/bin/zsh注销重进后 zsh 生效建议顺手配置一下 Oh My Zsh体验完全不一样。3.4 高频报错0x80370102 和 0x8007019e这两个报错出现的概率极高而且很多人第一次碰见都会一头雾水。error code: wsl/installdistro/service/registerdistro/createvm/hcs/error_file_n这类信息最终大概率指向两个原因CPU 虚拟化没在 BIOS 里打开。解决方法是重启进 BIOS找到 Intel Virtualization Technology 或者 SVM ModeAMD 平台设置为 Enabled。Windows 的 Hyper-V 相关功能没有完全启用。除了前面说的 VirtualMachinePlatform你还要确认“Windows 虚拟机监控程序平台”和“适用于 Linux 的 Windows 子系统”两项都在“启用或关闭 Windows 功能”里勾上了。至于 0x8007019e通常是因为 Windows 版本太老或者 WSL 内核组件缺失。先去官网下载并安装最新的 WSL 内核更新包再跑一次wsl --update大部分情况能解决。4. 把命令行体验提上来Windows Terminal、VSCode 和中文输入法装好系统只是开始真正决定你每天是否愿意用它的是终端好不好看、代码编辑器能不能顺手、中文能不能流畅输入。这一节我把这三件事一次讲透。4.1 Windows Terminal 的安装与配置要点微软商店下载 Windows Terminal基本无脑安装即可。但装完之后默认打开的可能是 PowerShell不是你的 Ubuntu。按 Ctrl逗号 打开设置在“启动”里把“默认配置文件”改为 Ubuntu-22.04 或者你装的发行版名字。之后就是字体和配色。我个人推荐使用 Cascadia Code 字体并且开启终端显示也支持等宽字体渲染。如果你经常在终端里敲中文建议把字体调成 “Sarasa Mono SC” 这类中英文都好看的开源等宽字体否则中文经常会被截顶或挤变。一个小技巧给 Ubuntu 配置文件单独指定一个配色主题比如深色背景 亮绿色文字可以让你长时间盯终端时眼睛舒服很多。这里面不用太纠结怎么顺眼怎么来。4.2 在 VSCode 中直接打开 WSL 项目在 VSCode 中使用 WSL 是官方支持的重度使用场景也是我日常用得最多的方式。你在 Ubuntu 里进入任意项目目录运行code .VSCode 会自动识别出当前环境是 WSL并在左下角显示一个类似 “WSL: Ubuntu-22.04” 的绿色标志。这时打开的终端、调试器、代码补全都跑在 Linux 环境里但 UI 还是 Windows 的流畅度比用虚拟机的远程桌面高太多了。有一个容易忽略的细节VSCode 需要安装微软官方的 “Remote - WSL” 扩展插件。首次使用它会自动在 WSL 里安装一个服务端组件如果你的网络状况不好可能卡在安装那一步。解决办法是检查 Windows 的防火墙是否拦截了 VSCode 的本地通信端口或者手动打开 WSL 终端的代理设置但尽量不要在大内网环境里做太复杂的网络改动保持默认最稳妥。4.3 Ubuntu 中文输入法的正确安装姿势很多人到 Windows 上装了 WSL打开 Ubuntu 之后发现没法输入中文这是一个很常见的卡点。因为 WSL 2 没有 GUI 的默认输入法框架你需要装一个能跑的输入法。实测下来搜狗输入法是不少国内用户的首选但在 WSL 里安装常会遇到依赖冲突的问题。我给你的建议是先装 Fcitx 框架再挂载中文输入法。步骤如下sudo apt install -y fcitx fcitx-googlepinyin然后在/etc/environment文件末尾追加GTK_IM_MODULEfcitx QT_IM_MODULEfcitx XMODIFIERSimfcitx这里有一个容易翻车的点你只是改了环境变量还不够必须重启 WSL 或者重启 Windows 才能让输入法框架生效。等重启后在终端里执行fcitx按 Ctrl空格 切出输入法。如果你用搜狗输入法建议先搜一搜对应 Ubuntu 版本是否支持常见做法是下载 deb 包后使用sudo dpkg -i安装遇到缺依赖就再执行sudo apt -f install修复。4.4 环境变量配置错误的自我修复在 Linux 里配置环境变量的坑很多人都有过阴影。最常见的情况是你为了装某个软件随手在~/.bashrc里写了两行export结果写错了路径导致所有终端一打开就报错而且报错信息一闪而过看不到真正的错误内容。我的建议是遇到这类问题先冷静用最原始的方式排查在 Windows 终端里执行wsl ~ -u root进入 root 模式然后用cat ~/.bashrc确认你之前写的 export 内容。大多数情况问题出在变量值里多了空格、缺了引号或者路径不存在。修正后执行source ~/.bashrc立刻验证是否恢复。如果你告诉我是PATH被改坏了命令都找不到那在 root 模式下跑export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin基本能救回来。5. 开发环境实战Docker、CUDA 与 PyTorch 的 WSL 落地WSL 2 真正厉害的地方是可以把以前只能在 Linux 服务器上跑的东西原样搬到 Windows 上。这节讲你能拿来直接用的开发环境搭建尤其是 Docker 和深度学习相关部分。5.1 在 Ubuntu 里安装 Docker 并运行 Python 环境装 Docker 的步骤其实不复杂但“能不能跑起来”往往取决于你有没有把用户加入 docker 组。常见流程如下sudo apt install -y ca-certificates curl sudo install -m 0755 -d /etc/apt/keyrings sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc之后把 Docker 的 apt 源写入/etc/apt/sources.list.d/docker.list具体版本对应你的 Ubuntu 版本号。然后执行sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin安装完成后执行sudo systemctl enable docker sudo systemctl start docker sudo usermod -aG docker $USER把普通用户加入 docker 组是为了以后运行docker ps不需要加 sudo。注意WSL 里的 systemd 在旧版本是默认关闭的如果你执行systemctl失败先检查一下你的 Ubuntu 版本。在较新的 WSL 版本里你可以在/etc/wsl.conf中加一段[boot] systemdtrue然后重启 WSL再执行 systemctl 就能正常工作了。跑一个 Python 环境测试docker run --rm -it python:3.12-slim bash进入容器后运行python --version看到版本号就说明 Docker 链路完全通了。5.2 WSL 下装 CUDA 的正确姿势与显卡驱动关系在 WSL 里跑深度学习最让人困惑的就是显卡驱动。记住一个关键点不要想着在 WSL 里的 Ubuntu 再单独装一套 NVIDIA 显卡驱动你应该装的是 Windows 侧的最新 NVIDIA 驱动。WSL 2 会通过 GPU 直通 demo 机制访问 Windows 上的显卡驱动。具体操作是先去 NVIDIA 官网下载 Windows 最新驱动安装时选“自定义安装”确认勾选“物理 GPU 虚拟化支持WSL 2”。然后进入 Ubuntu装 CUDA Toolkitwget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-keyring_1.1-1_all.deb sudo dpkg -i cuda-keyring_1.1-1_all.deb sudo apt update sudo apt install -y cuda之后把 CUDA 路径写入~/.bashrcexport PATH/usr/local/cuda/bin:$PATH export LD_LIBRARY_PATH/usr/local/cuda/lib64:${LD_LIBRARY_PATH}运行nvidia-smi如果能显示 Windows 上那块 GPU就说明链路通了。此时在 Ubuntu 内执行nvcc --version也能看到 Toolkit 版本。这里补充一个重要区别Windows 的nvidia-smi显示的是驱动本身支持的 CUDA 版本你 Ubuntu 里安装的 CUDA Toolkit 是另一个层面的东西两者不必完全一致只要驱动版本 Toolkit 要求的最低版本就行。5.3 搭建 PyTorch 环境的实战记录在 WSL 里搭 PyTorch思路和 Linux 原生环境基本一致。我建议先创建虚拟环境再装框架避免污染系统 Pythonpython3 -m venv ~/venv/pytorch source ~/venv/pytorch/bin/activate pip install --upgrade pip pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118版本号可以换成cu121或新一点的 CUDA 版本按你的 toolkit 版本来。装完之后写一小段代码验证 GPU 是否可用import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))如果输出True和一块显卡名字说明 GPU 环境已经全部打通。实测在 WSL 里训练和推理的性能与原生 Linux 几乎一致除非你用到极其特殊的硬件特性否则完全可以作为主力环境。5.4 端口互通的坑Windows 和 WSL 的监听规则Windows 和 WSL 2 的网络是 NAT 模式默认情况下 WSL 里启动的服务的端口会映射到 Windows 侧。也就是说你在 Ubuntu 里运行python manage.py runserver 8000然后在 Windows 浏览器直接访问localhost:8000通常是可以通的。但问题容易出在“端口占用”和“反向访问”。比如 Windows 上已经有一个服务占用了 8000 端口WSL 里的服务启动后可能会冲突你需要在 Windows 上查清占用并关掉它。命令如下netstat -ano | findstr :8000 taskkill /PID 进程号 /F如果你用的是 Windows 11 的较新 WSL 版本NAT 模式的细节可能变了那么简单粗暴的做法是查 WSL 的 IP然后用 IP 访问hostname -I在 Windows 浏览器里输入这个 IP 加端口号。遇到跨系统访问很慢或者不通的情况优先确认 Windows 防火墙是否放行了对应端口尤其当你觉得“我明明启动了服务可 Windows 就是访问不了”的时候。6. 最容易踩坑的五个场景以及对应的处理思路这些年我在用 WSL 的过程中几乎每个阶段都撞过一些让人头大的问题。这些问题的通用性很强我梳理了五个典型场景把根因讲清楚。6.1 WSL 里启动 Windows 守护进程时报错的背后很多人跑某些 Windows 工具时会看到这样一段话error: start the windows daemon from a non-elevated terminal; shared clients或者类似提示意思是某个守护进程需要从非管理员权限的终端启动。我一开始没搞明白后来才想通这是 Windows 对权限隔离的设计很多后台守护进程希望以普通用户身份运行避免给整个系统过高的权限。如果被这句话卡住最简单的操作是关闭当前的“以管理员身份运行”终端重新用普通用户权限打开 PowerShell 或 Windows Terminal再启动对应命令。一句话总结看到“non-elevated terminal”就先把你的管理员窗口关掉。6.2 弹性文件性能问题不要跨系统频繁读写代码我在第三节提到过WSL 2 的跨文件系统访问性能差。很多人习惯把项目放在D:\projects\myapp然后在 WSL 里用/mnt/d/projects/myapp访问。对一个体量不大的项目来说编译和运行尚可接受但如果你用 Node.js 或者 Python 依赖很多的小文件包速度会慢到你怀疑人生。根因在于 WSL 2 的/mnt/d是通过 9P 协议访问 Windows 文件系统每一次文件读取都要穿过协议层。正确做法是把项目放到 WSL 自己的文件系统里也就是/home/yourname/projects/。你仍然可以用 VSCode 远程连接 WSL 来编辑代码数据实际存储在 Linux 侧飞一般的感觉就回来了。6.3 配置了环境变量却死活不生效环境变量不生效是特别容易让人挫败的问题。你明明在~/.bashrc里写了export PATH...新开终端却找不到命令。我见过的情况里有八成是因为变量设置写在某个错误行之前被后面的同名 export 覆盖了也有小部分是忘了用export直接写成了PATHxxx。建议每次修改完环境变量都统一执行grep -n export PATH ~/.bashrc确认你的设置是最后出现的并且没有重复。想更彻底地定位的话在登录 shell 和非登录 shell 的差异上花点时间~/.bashrc是交互式 shell 读取的而~/.profile或~/.bash_profile是登录式 shell 读取的。如果你只改了一个文件可能在某种场景下就是不生效。6.4 在 WSL 里卸载 GPU 驱动导致的连锁问题搜索热词里有“ubuntu显卡驱动卸载不掉”这通常发生在原生 Ubuntu 上。如果你在 WSL 场景下误装了 Linux 侧显卡驱动然后用常规方式卸载反而可能把系统搞崩。WSL 里本来不需要也不应该装额外的 NVIDIA 驱动你只要保证 Windows 侧驱动正常即可。如果已经发生卸载不了或者系统异常的情况我的建议是优先检查启动级别和内核模块lsmod | grep nvidia如果模块还在说明驱动还在加载。用官方卸载脚本前先做好方案备份最保守的做法是直接把 Ubuntu 发行版重置或者重装因为 WSL 里你真正重要的数据只有家目录这个代价可接受。6.5 虚拟化嵌套在 WSL 里用 Docker 时需要关注的内核特性Docker 在 WSL 2 内部运行时其实是 Ubuntu 虚拟机和 Docker 守护进程的嵌套。由于 WSL 2 已经内置了对嵌套虚拟化的支持绝大多数情况下systemctl start docker或直接使用 Docker Desktop 都能跑。但只要你启用了 systemd并且端口映射时出现奇奇怪怪的问题例如容器里访问不了外网请优先检查 Docker 的 DNS 配置而不是怀疑 WSL 本身。你在/etc/docker/daemon.json里可以临时配置 DNS{ dns: [8.8.8.8, 1.1.1.1] }改完重启 Docker。这类“不是 WSL 的事”的判断能力往往比配置本身更重要。7. 我用了这么久的 WSL最后分享几个真经验跟 WSL 相处久了你会慢慢形成一套自己的使用习惯。最后这一部分我想给大家一条重要的心态和几个实用技巧这些都不是从官方文档里看来的而是实打实在使用过程中试出来的。7.1 把 Windows 和 WSL 当成一个整体来用很多人的使用误区是把 Windows 和 WSL 割裂开在 Windows 上做 Windows 的事在 WSL 上做 Linux 的事两边倒腾文件要来回 copy。其实更顺手的做法是把代码和项目全部放在 WSL 的文件系统里用 VSCode 连接 WSL 写代码用 Windows 打开浏览器看效果Windows 侧只负责那些 WSL 覆盖不到的场景比如某些专业软件、Office 文档、国内常用工具。文件互访也尽量用 WSL 的路径语义。你在 Windows 资源管理器地址栏输入\\wsl$\Ubuntu-22.04\home\yourname就能直接看到 Linux 里的文件完全不需要额外装软件。7.2 通过 .wslconfig 定制资源上限如果你发现自己 Windows 内存经常不够用或者恰恰相反想让 WSL 获得更多资源可以在用户目录下建一个.wslconfig文件内容类似[wsl2] memory8GB processors4 swap4GB localhostForwardingtrue改完执行wsl --shutdown再重启 WSL。注意这里的localhostForwardingtrue是允许 Windows 通过 localhost 访问 WSL 服务的开关默认就是开着的你不需要手动确认但如果你曾经把它关掉过很多端口问题就会出现。7.3 善用快照与备份避免“一失足成千古恨”WSL 的整个系统是个虚拟磁盘VHDX 文件你可以定期把它导出备份。备份命令我在前面讲过wsl --export即可区别是备份体积通常很大几十 GB。对日常使用者来说你可以只备份/home目录里的关键数据用 rsync 同步到 Windows 侧或者网盘rsync -av --progress ~/projects /mnt/d/backup/这个习惯能让你的开发环境在任何一次误操作或系统崩溃后快速恢复到可用状态。我自己的数据除了放在代码仓库里还会定期同步一份到家目录以外的地方多次救过我的命。7.4 遇到问题先拆解再搜索最后说一个方法论层面的经验。碰到 WSL 报错不要先急着复制整段错误去搜索而是拆解错误信息里的关键字发行版名称、错误码、服务名、文件路径。比如前面那个createvm/hcs/error_file_n看起来很长但关键信息就是createvm和error_file_n前者提示你问题出在创建虚拟机这一步后者提示文件缺失。一旦定位到这一步你再去查对应的虚拟化设置和文件权限会比盲目搜整段原文高效得多。用 WSL 玩转 Ubuntu 这件事说难也难说简单也简单。难在你需要理解很多底层逻辑和 Windows 与 Linux 的交界之处简单在于一旦你摸熟了这套链路你的日常开发效率会有质的提升。如果有哪个环节卡住照着这篇的思路拆解问题大概率能自己找到答案。