企业官网建设流程全解析

在 Windows 上折腾 Linux 开发环境，过去绕不开双系统或者虚拟机。双系统重启切换太麻烦，虚拟机又始终隔着一层，性能损耗和内存占用都肉眼可见。这两年我基本固定在一套组合里：Windows 11 + WSL 2 + Ubuntu 24.04，日常的 Python 脚本、Docker 容器、Redis/MySQL 这些服务、甚至 PyTorch 训练，都在这套环境里完成。这篇文章就把我实际跑通的流程、踩过的坑、以及排查经验一次性整理出来，希望给准备在 Windows 上用 WSL 玩转 Ubuntu 的人一个可复制的路线图。

适合谁看？想试试 Linux 生态但暂时离不开 Windows 的开发者、做数据分析的同学、需要跑 Linux 工具链的运维，以及所有被虚拟机性能搞到崩溃又不想双系统的朋友。文章里不仅有安装命令，更重要的是那些报错信息和排查思路，很多是我一步一步试出来的。

1. 为什么非要在 Windows 里跑 Ubuntu：WSL 到底帮你解决了什么

1.1 一句话理解 WSL：Windows 里的 Linux 子系统

WSL 全称是 Windows Subsystem for Linux，也就是 Windows 提供的 Linux 兼容层。很多人第一次听到这个概念会懵：这不就相当于虚拟机吗？其实不一样。虚拟机是在 Windows 上模拟出一整套硬件再装 Linux，开销大、启动慢；而 WSL 是微软从系统层面实现的 Linux 运行环境，它不跑完整硬件模拟，而是直接复用 Windows 的内核能力，因此启动只要几秒钟，内存占用也小得多。

WSL 1 和 WSL 2 有本质区别。WSL 1 用的是系统调用翻译技术，把 Linux 的底层调用翻译成 Windows 能理解的指令，兼容性不算完美；WSL 2 则换成了轻量级虚拟机方案，内置了一个真正的 Linux 内核，文件系统、网络协议、系统调用基本都是原生行为。我强烈建议直接上 WSL 2，虽然它本质上还是虚拟机架构，但微软做了大量优化，日常开发几乎感觉不到底层是 VMware 还是 Hyper-V 那套东西。

1.2 WSL 1 和 WSL 2，选错版本多走半年弯路

我先用一张表把两个版本的区别列出来，后续所有操作都默认你用的是 WSL 2。

有个常见误解：WSL 2 的文件系统性能一定差。它只是访问 Windows 挂载的目录（比如 /mnt/c/）时比较慢，如果你把所有代码都放在 Linux 侧的文件系统里，性能完全没问题。我自己一开始把项目放在 D 盘然后用 WSL 去读，编译慢到想砸电脑；后来全部移到 Linux 目录，速度立刻恢复正常。

1.3 什么样的人最应该玩转 WSL

我用 WSL 这么久，身边问得最多的几类人都有一个共同特点：不愿意彻底放弃 Windows，但又需要 Linux 环境干活。比如做 web 开发的，线上服务器是 Ubuntu，本地想尽量复现线上环境；比如做运维的，天天要敲 bash 脚本，Windows 的 PowerShell 虽然强，但很多 Linux 工具链装起来依然别扭；还有做深度学习的学生，装 PyTorch 时发现 Linux 的包管理和 GPU 驱动支持更省心。

也有不适合的场景。如果你需要跑带图形界面的完整 Linux 桌面、需要大量 GUI 开发，或者要测试 UEFI 启动、内核调试这类底层内容，那还是乖乖用虚拟机或物理机装 Ubuntu。WSL 的定位是"开发环境"而非"桌面系统"，这句话早点理解能省掉很多纠结。

2. WSL 安装避坑实录：从一行命令到顺利进入 Ubuntu

2.1 装之前先自查：系统版本、虚拟化和权限检查

安装 WSL 本身不难，但很多人卡在各种环境检测上。第一步是确认 Windows 版本。Win+R 输入winver回车，弹出来的窗口会显示系统版本。如果还是 Windows 10 老版本，WSL 2 的支持并不完整，建议升级到 Windows 10 21H2 及以上，或者直接用 Windows 11。Windows Server 2022 也能装 WSL 2，但需要通过手动安装 MSI 包的方式升级组件，后面我会单独讲。

第二步是检查虚拟化是否开启。WSL 2 依赖 Windows 的虚拟机平台和 Hyper-V 组件，如果你的 CPU 虚拟化被禁用了，安装后大概率报错。打开任务管理器，在"性能"页看"虚拟化"一栏，如果显示"已启用"就跳过；如果显示"已禁用"，需要进 BIOS 找到 Intel VT-x / AMD SVM 相关选项并打开。笔记本用户尤其注意，某些品牌的 BIOS 默认关闭虚拟化，这步不检查后面全是坑。

第三步是用管理员权限打开 PowerShell 或 Windows Terminal。右键开始菜单就能看到"终端（管理员）"入口。按Win+X，选"Windows 终端 (管理员)"。权限不足会导致后续 WSL 相关命令执行失败，或者提示无法安装 Windows 功能。

2.2 最快安装路径：wsl --install 一条龙

从 Windows 10 21H2 和 Windows 11 开始，最省事的做法就是一条命令：

wsl --install

这条命令会自动开启"适用于 Linux 的 Windows 子系统"和"虚拟机平台"两个 Windows 功能，然后去微软商店下载并安装默认的 Ubuntu 发行版，整个过程可能意外地顺利。如果想指定安装某个版本，比如 Ubuntu 22.04，可以加参数：

wsl --install -d Ubuntu-22.04

执行完命令后一般会提示你重启系统。重启完成后，开始菜单里就能看到 Ubuntu 的图标，第一次点击它会进入初始化界面，创建 Linux 账号和密码。

这里有个细节：wsl --install现在默认使用的是 WSL 2。如果你的系统比较老，安装完想确认版本，可以用wsl -l -v查看。如果发现还是 WSL 1，手动切换到 2 的命令是：

wsl --set-version Ubuntu-22.04 2

2.3 下载太慢/卡住的替换方案：手动下载导入

现实中有一大批人卡在wsl --install的下载环节，进度条死活不走。这主要是因为发行版镜像要从微软的服务器拉取，网络环境一变就很容易挂掉。遇到这种情况，官方商店的下载通道大概也快不到哪去，但你可以试试从 Ubuntu 官网获取面向 WSL 的 rootfs 压缩包，然后手动导入。

具体操作分两步。先到 Ubuntu 官网下载对应的 WSL 专用镜像文件，注意不是桌面版 ISO 那种几百 MB 的安装镜像，而是用于 WSL 的 tar.gz 格式 rootfs 包。下载后把文件放到 D 盘某个目录，比如D:\wsl\，然后在 PowerShell 里执行：

mkdir D:\wsl\ubuntu2204 wsl --import Ubuntu-22.04 D:\wsl\ubuntu2204 D:\wsl\ubuntu-22.04.tar.gz --version 2

wsl --import会把 Linux 根文件系统导入到你指定的目录，--version 2强制使用 WSL 2。导入完成后，用wsl -d Ubuntu-22.04进入，但是默认用户会是 root，而不是正常安装时让你创建的普通用户。解决方法是进去之后创建一个用户，然后写一个/etc/wsl.conf配置文件，把默认用户指过去：

[user] default=你的用户名

改完配置文件，在 PowerShell 里执行wsl --shutdown再重新进入，默认用户就正常了。手动导入这条路径我第一次操作时花了二十分钟，熟悉之后就五分钟的事，比较适合网络状况一般的情况。

2.4 首次启动 Ubuntu：创建 Linux 账户与密码

如果你是通过wsl --install正常安装的发行版，第一次启动 Ubuntu 会提示 "Enter new UNIX username" 和 "Enter new UNIX password"。这里输入的账号密码，和 Windows 登录账号完全无关，它是 Ubuntu 容器里的独立账号，之后执行sudo命令时用的也是这套密码。

一个小提示：Linux 输密码时不会显示任何字符，这是终端世界的安全习惯，别以为键盘没反应，正常敲完回车就行。账号名建议全小写，因为 Linux 用户名是区分大小写的，万一后面要配 SSH 或者容器，全小写能少很多麻烦。

创建完账号后，可以立刻检查一下基础状态：

uname -a cat /etc/os-release

uname -a能看到内核版本，/etc/os-release能确认 Ubuntu 的具体版本号。到这一步，WSL 的基本框架已经搭好，接下来可以开始规划这个"Linux 小盒子"怎么用了。

3. 进入 Ubuntu 后的第一课：换源、补齐基础工具与资源配额

3.1 apt 换源：别让包下载等哭你

装完 Ubuntu 头一件事，我建议先把apt软件源的下载地址切换成国内镜像。不做这一步，你用sudo apt install gcc都可能卡到怀疑人生。判断自己的 Ubuntu 版本有个标准动作：

ls /etc/apt/sources.list.d/

在 Ubuntu 22.04 上，一般看到的是/etc/apt/sources.list；到了 Ubuntu 24.04，系统改成了/etc/apt/sources.list.d/ubuntu.sources这种 deb822 格式。改之前先备份，这是我在服务器上养成的基本习惯：

sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak

然后根据自己的版本，把源地址整体替换成阿里云或清华的镜像。比如 22.04 的替换方式：

sudo sed -i 's@//archive.ubuntu.com@//mirrors.aliyun.com@g' /etc/apt/sources.list sudo sed -i 's@//security.ubuntu.com@//mirrors.aliyun.com@g' /etc/apt/sources.list sudo apt update

如果是 24.04，则要编辑ubuntu.sources文件，把http://archive.ubuntu.com/ubuntu/替换成http://mirrors.aliyun.com/ubuntu/。替换完成后，顺手跑一遍：

sudo apt update && sudo apt upgrade -y

看到下载速度从几 KB/s 跳到几 MB/s 的时候，你就知道这步有多值了。

3.2 基础工具链安装：顺手的工作环境

换完源，我通常会一次性装好一组基础工具，覆盖编译、网络、文本处理和系统监控。命令如下：

sudo apt install -y build-essential git curl wget net-tools htop tree zip unzip

build-essential包含 gcc、g++、make 等编译工具链，很多软件安装时都需要；net-tools提供ifconfig、netstat等经典网络命令，虽然新系统已经在推ip命令，但很多文章和脚本里还是老写法；htop是交互式系统监控工具，比top好看又好用。如果你有 Java 开发需求，顺手装个 JDK 17 也很简单：

sudo apt install -y openjdk-17-jdk java -version

如果你对 APT 安装的版本不放心，也可以到 JDK 官网下载对应的 Linux 包手动安装，但在 WSL 里用 APT 足够日常开发用了。做固件分析或者逆向的同学，可以在后面补一个binwalk：

sudo apt install -y binwalk

Binwalk 在 Ubuntu 仓库里可以直接装，不需要编译半天，这点比在 Windows 上找工具舒服太多。

3.3 Windows Terminal：管理 WSL 的舒服姿势

从 Windows 商店下载 Windows Terminal，是我给所有 WSL 用户的统一建议。它不是一个终端模拟器那么简单，而是把 PowerShell、CMD、Ubuntu 这些所有终端环境整合到同一个窗口里。装好之后，打开 Windows Terminal，点标题栏的下拉箭头，就能看到 Ubuntu 的入口，选完直接进入，无需多余配置。

Windows Terminal 有几个小技巧很实用：设置里可以调整透明度、背景图，适合长时间盯终端的人；快捷键Ctrl+Shift+T开新标签页，Ctrl+Shift+D复制当前标签页，Alt+Shift+D分屏。分屏功能尤其在"一边跑服务一边看日志"的场景下非常好用，一边开 WSL 跑 Elasticsearch，一边开 PowerShell 检查端口，互不干扰。

然后谈一个常用的灵巧用法：在 WSL 终端里输入：

explorer.exe .

Windows 的资源管理器会立刻弹出，当前目录正好是 WSL 里的工作目录。反过来，Windows 文件管理器地址栏输入\\wsl$\，就能像访问网络共享一样访问 WSL 的整个 Linux 文件系统，拖拽文件非常方便。

3.4 用 .wslconfig 给 WSL 定规矩：内存和 CPU 管起来

WSL 2 有个让很多人头疼的默认行为：最多能占用 Windows 总内存的 50%，磁盘缓存也会慢慢膨胀。如果你电脑只有 8GB 内存，跑一个 Elasticsearch 或者 Docker 容器，Windows 端可能卡到鼠标都动不了。解决办法是在用户目录下建一个.wslconfig文件来限制资源。

.wslconfig文件位置在C:\Users\你的用户名\.wslconfig，不存在就自己创建。内容示例：

[wsl2] memory=8GB processors=4 swap=4GB localhostForwarding=true

memory限制 WSL 最大内存，processors限制 CPU 核数，swap分配交换空间大小。我自己的机器是 32GB 内存，设的memory=12GB，既能保证 WSL 里跑 Docker 和编译任务不崩，也能让 Windows 端微信、浏览器继续流畅。

改完.wslconfig后一定要在 PowerShell 里执行：

wsl --shutdown

等两秒再重新打开 WSL，配置才会生效。这个坑我踩过：改完配置不看教程直接重启电脑，结果配置并没有加载，折腾半天才发现要对 WSL 实例完整断电重启。

4. 开发环境搭建实战：Docker、数据库、AI 环境一条龙

4.1 Docker 在 WSL 里的两种正确姿势

Docker 是 WSL 用户绕不开的话题，也是最容易踩坑的地方。先说结论：WSL 2 本身就支持 Docker，问题是 Docker 守护进程在默认的 WSL 环境里启动方式有点绕。你在 WSL 里执行systemctl start docker，大概率会收到System has not been booted with systemd as init system (PID 1). Can't operate.的报错。这就要引入一个关键概念：systemd。

WSL 默认使用一个很精简的 init 进程，不像真实 Linux 那样跑完整 systemd，很多服务管理命令直接不可用。解决办法是在/etc/wsl.conf配置中开启 systemd：

[boot] systemd=true

保存后执行wsl --shutdown再重新进。之后systemctl命令就能正常使用了。开启 systemd 之后，在 WSL 里安装 Docker 有两种方案，我把对比列出来：

我个人更推荐 WSL 内直接装 docker-ce，因为它在 WSL 的 Linux 环境里逻辑最简单，也不占 Windows 侧的资源。安装步骤是：

sudo apt update sudo apt install -y docker.io sudo service docker start sudo systemctl enable docker docker ps

设置 Docker 开机自启还需要注意：WSL 实例每次启动都会重新初始化 systemd，开了 systemd 后systemctl enable docker基本就能用了。如果你要用docker compose，再补一个：

sudo apt install -y docker-compose-v2

4.2 Redis、MySQL 这类服务怎么在 WSL 里跑起来

数据库服务的思路和 Docker 类似，有了 systemd，安装就变成一条龙。Redis 最典型：

sudo apt install -y redis-server sudo systemctl enable --now redis-server redis-cli ping

正常会返回PONG，说明服务已经跑起来了。默认的 Redis 只绑定 127.0.0.1，如果之后要配合 Windows 上的客户端一起用，可以让它监听所有地址。不过这里我不建议直接改bind 0.0.0.0，更安全的做法是在 Windows 侧用localhost访问，因为 WSL 2 默认开启了 localhost 转发。也就是说，你在 Windows 上打开 Redis 的可视化客户端，连接地址直接填127.0.0.1就可能连上 WSL 里的 Redis。

MySQL 的安装也别怕，继续用 systemd 流程：

sudo apt install -y mysql-server sudo systemctl enable --now mysql sudo mysql_secure_installation

注意 WSL 里 MySQL 默认的 root 认证方式有时是 auth_socket，导致你用mysql -u root -p也进不去。解决办法是进入 MySQL 之后改认证插件，这个很容易搜到，但根源在于 WSL 环境里没有 systemd 的正常多用户会话，数据库安装逻辑和普通 Ubuntu 略不同。如果你装 Elasticsearch 这类 Java 服务，碰到启动直接挂掉的情况，八成是 JVM 堆内存设置过大或者vm.max_map_count参数太低，最常用的修复是：

sudo sysctl -w vm.max_map_count=262144

然后就放心在 WSL 里搭一套完整的服务集群吧，端口映射那几个细节我会在 4.4 展开。

4.3 VS Code 联动 WSL：用最习惯的编辑器写 Linux 代码

VS Code 和 WSL 的组合，是我认为整个 WSL 体验里最惊艳的部分。默认情况下，WSL 里也有一个code命令，但它能否唤起 Windows 侧的 VS Code，完全取决于你装没装 Remote Development 扩展。

在 Windows 侧的 VS Code 装好 "Remote Development" 扩展包后，进入 WSL 终端，直接输入：

code .

VS Code 会自动以 WSL Remote 模式打开当前目录。这个模式的厉害之处在于：窗口界面在 Windows，但文件系统、终端、扩展、调试器全都在 Linux 侧运行，代码补全也按照 Linux 环境来。你在 Windows 侧装的 VS Code 扩展不会自动出现在 WSL 里，每个扩展右上角会有"在 WSL 中安装"的选项，头一次可能不习惯，后面就会觉得这个隔离设计非常科学。

我自己的主力工作流就是：WSL 里托管代码和依赖，VS Code Remote 写代码，Windows 侧开浏览器和数据库客户端。比如做 Spring Boot 的一个小服务，WSL 里跑mvn spring-boot:run，Windows 浏览器直接访问localhost:8080，日志就在 VS Code 的集成终端里滚动，整套链路丝滑得很。

4.4 文件互通与端口转发：Windows 和 Linux 的边界处理

WSL 2 的跨系统文件访问有一个显著特点：从 Linux 访问/mnt/c/下的 Windows 文件会比较慢，因为要经过 9P 协议桥接；但反过来，Windows 访问 WSL 内的文件反而很快，因为 WSL 用了 VHD 虚拟磁盘。所以我的习惯是：所有代码和项目文件都放在 Linux 侧，需要和 Windows 交换数据时，用小文件走explorer.exe .拖拽，大文件直接放在\\wsl$\目录里。

端口这块有个很容易误解的点：默认情况下，Windows 可以通过localhost访问 WSL 里启动的服务，但同一个局域网里的其他电脑并不能直接访问这个端口。比如你 WSL 里跑了一个端口 8080 的 web 服务，想用手机连接你电脑看效果，就需要做端口转发。Windows 侧管理员 PowerShell 里执行：

netsh interface portproxy add v4tov4 listenport=8080 listenaddress=0.0.0.0 connectport=8080 connectaddress=127.0.0.1

这会把 Windows 的 8080 端口转发到 WSL 的 8080。如果你以后想删掉这条规则：

netsh interface portproxy delete v4tov4 listenport=8080 listenaddress=0.0.0.0

另一种办法是手动查看 WSL 的 IP 地址，然后局域网电脑直接访问该 IP，但问题是 WSL 2 的 IP 每次重启都可能变，所以我更推荐 netsh 端口转发方式，一劳永逸。

还有一种更常见的情况，你在 Windows 上需要监听某个端口，但发现已经被占用。排查和关闭流程很经典：

netstat -ano | findstr :8080 taskkill /PID 12345 /F

同样逻辑也适用在 WSL 里，把netstat换成 Linux 的ss -tlnp即可。

4.5 在 WSL 里配置 PyTorch 与 CUDA：深度学习也能玩

很多做深度学习的朋友以为 WSL 只能跑点 Linux 命令，其实 WSL 2 对 NVIDIA GPU 的支持已经非常成熟，这也是我当初从 VMware 转 WSL 的核心原因。在 WSL 里，你不需要单独装 Linux 版显卡驱动，直接用 Windows 侧安装的 NVIDIA 驱动即可。进入 WSL 终端后输入：

nvidia-smi

如果能看到显卡信息，说明 GPU 直通已经生效。从这一步开始，本质就和一个真 Ubuntu 的深度学习环境差不多了。

然后装 Miniconda：

wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh

装完之后记得source ~/.bashrc加载 conda 命令，然后创建虚拟环境并安装 GPU 版 PyTorch：

conda create -n pytorch python=3.11 -y conda activate pytorch pip install torch --index-url https://download.pytorch.org/whl/cu121

最后验证：

python -c "import torch; print(torch.cuda.is_available())"

输出True就说明一切正常。整个过程二十分钟足够了，丝毫不输原生 Ubuntu。如果你是 AMD 显卡用户，比如 7900 XTX，那要绕道 ROCm 方案，WSL 下的支持度和可玩性远不如 NVIDIA，建议多查查对应版本的兼容矩阵再做决定。

4.6 本地模型部署与 AI 编程工具的小扩展

这两年 AI 编程工具很火，比如 OpenAI 的 Codex CLI、各种本地模型部署工具，在 WSL 里跑反而比原生 Windows 更省心，因为很多工具直接发的是 Linux 二进制。我自己在 WSL 里跑过 Codex CLI，安装依赖、调用本机的 Python 环境，统统不用纠结 Windows 路径问题。如果你有本地大模型部署的需求，WSL 也不是不行，像 DeepSeek 这类模型通过 Ollama 在 WSL 里跑，性能开销完全可控，前提是显存和内存足够，最好在.wslconfig里预留充足配额。

不过提醒一句：WSL 里的本地部署只适合个人研究和开发，真要稳定长期服务，还是建议用专业的 Linux 服务器。WSL 的价值在于"开发环境一致性"，不是说它要变成生产服务器。把这种心态摆正，工具用起来才会顺手。

5. 高频报错排查与避坑技巧：照着抄就行

5.1 提示 WSL needs updating 或者版本过旧

Windows Server 2022 和某些精简版 Windows 上，经常出现wsl needs updating的提示，意思是你系统自带的 WSL 组件太旧，需要升级到商店版本。解决办法是在 PowerShell 里：

wsl --update

如果提示找不到更新或者更新失败，去微软官方 GitHub Release 页面下载 WSL 的最新 MSI 安装包，手动安装即可。装完记得确认：

wsl --version

能看到 WSL 版本信息就说明安装成功。这个坑在 Windows Server 上特别多，跳过不处理的话后续装什么发行版都会报错。

5.2 安装卡在进度条或者下载特别慢

wsl --install卡在启动状态弹不出来，或者下载进度条几乎不走，常见原因有两个：一个是发行版镜像下载慢，一个是后台服务被安全软件拦截。优先换手动导入方案，用 2.3 节说的方法从镜像站下载 rootfs 包然后wsl --import，这条路基本不受 Windows 商店网络限制。

另一个解决思路是直接去微软商店搜 Ubuntu，点安装，商店的下载通道有时候和命令行通道不一样，偶尔命令行卡住商店反而能正常装。我在两台电脑上一个用命令行一个用商店，效果差别挺大。如果这些都试了还是不行，也可以试试重启 Windows 服务Windows Update和Microsoft Store Install Service。

5.3 Ubuntu 环境变量配置错误导致终端打不开

有次我把PATH改坏了，结果一打开 WSL 终端就提示-bash: ls: command not found，输入啥都没反应，因为系统所有命令都找不到了。很多人到这一步直接重装系统，其实有救。

在 PowerShell 里以 root 身份进入发行版，并用一个干净的环境启动 bash：

wsl -u root

如果没有设置默认 root 密码，root 用户可能无法直接登录。常规做法是在 Windows 终端执行：

wsl -u root -e /bin/bash --noprofile --norc

--noprofile --norc的意思是绕过所有启动脚本，直接给一个干净 shell。进去后手动恢复PATH，比如：

export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

然后用这个干净环境去修复~/.bashrc或/etc/profile.d/里的错误配置。如果还是不行，wsl --unregister Ubuntu-22.04然后重装，但这会把里面所有数据清空，属于最后手段。我的心得是：改环境变量前先备份，或者至少写好注释。

5.4 忘记 Ubuntu 密码

密码忘了不要慌，在 PowerShell 里直接指定 root 用户进入：

wsl -u root

进去之后用passwd修改你想重置的用户密码：

passwd 你的用户名

回车，输入两次新密码就可以。我现在越来越习惯把常用密码放在密码管理器里了，WSL 的密码虽然不常用，但一旦忘了就是无底洞。

5.5 端口被占用：在 Windows 上和 WSL 里分别怎么关

日常开发最常见的卡点就是端口冲突。Windows 侧查端口占用的命令：

netstat -ano | findstr :8080

看最后一列 PID，然后强制结束进程：

taskkill /PID 12345 /F

WSL 侧用ss命令更直观：

ss -tlnp | grep 8080

能看到哪个服务占用了端口，配合kill PID就能解决。如果你发现 WSL 里的服务在 Windows 上访问不到，也先别急着折腾防火墙，确认一下 localhost 转发是否开启。在.wslconfig里设置localhostForwarding=true是默认行为，但如果之前手动改过，就会影响 Windows 访问 WSL 服务的行为。

5.6 Ubuntu 中文输入法、字体等界面问题

WSL 里要不要装中文输入法，取决于你有没有用 WSLg 去跑 Linux 图形化界面。如果你用的是 Windows 11 自带 WSLg，想直接在 WSL 里开一个带界面的 GUI 应用，那确实需要装中文字体和输入法。方案一般是 fcitx5：

sudo apt install -y fcitx5 fcitx5-chinese-addons fonts-noto-cjk

配置环境变量：

export GTK_IM_MODULE=fcitx export QT_IM_MODULE=fcitx export XMODIFIERS=@im=fcitx

然后重启 WSL。说实话，多数情况下我并不推荐在 WSL 里折腾图形界面和输入法，因为 WSL 的定位是命令行和后台服务，图形界面在 Windows 侧已经有了很成熟的方案。如果真需要长期使用 GUI，请回看 1.3 的场景分析。

还有一个玄学问题：在 WSL 里执行 GUI 程序时显示方框乱码，基本是缺少中文字体所致，装fonts-noto-cjk可解决；如果出现一打开 GUI 就闪退，先看看 Windows 侧是否启用了"适用于 Linux 的 Windows 子系统 GUI"功能，进系统设置确认 WSLg 相关组件是打开的。

最后再分享一句实在话

WSL 绝不是万能的，但它确实解决了"Windows 和 Linux 只能二选一"这个老问题。我用了这几年，最大的体会是：提前把资源配额、systemd、软件源、端口转发这几件事做好，WSL 的体验会稳定到让你忘记它底层是一个虚拟机。希望这篇文章能帮你少走弯路，把更多时间花在真正值得研究的事情上。如果你在实操中遇到别的报错，欢迎按照文章里的排查思路一步步来，大多数问题都逃不出环境、配置、网络这三件事。