s-blog

我的 WSL 2 初始化清单：性能、资源、网络与目录规划

Windows 11 + Ubuntu 26.04 的实机初始化记录

ssssmy · 2026-08-18 · 7 min · Ubuntu

我的 WSL 2 初始化清单：性能、资源、网络与目录规划

刚安装好的 WSL 可以直接使用，但默认状态未必适合长期开发。这次我在一台 Windows 11、64 GB 内存、24 线程的机器上初始化 Ubuntu 26.04，目标不是立即堆满开发工具，而是先把系统更新、资源边界、网络、代理、目录和健康检查处理好。

本文中的 32 GB 内存、16 个处理器和 8 GB Swap 是针对这台机器的配置示例，不是通用答案。请按自己的硬件调整。

一、先确认基础状态

在 PowerShell 中检查 WSL 本体和发行版：

wsl --version
wsl --status
wsl --list --verbose
wsl --update

应重点确认：

  • 发行版运行在 WSL 2，而不是 WSL 1；
  • WSL 已更新到当前可用版本；
  • Ubuntu 能正常启动；
  • 新版 Ubuntu 通常已经默认使用 systemd。

进入 Ubuntu 后验证 PID 1：

ps -p 1 -o comm=

输出为 systemd 即可。旧发行版如果没有启用，可以参考 Microsoft 的 WSL systemd 文档。

二、只更新系统，不急着安装开发工具链

首次启动后先完成系统更新：

sudo apt update
sudo apt full-upgrade -y
sudo apt autoremove -y
sudo apt clean

再做几个低成本健康检查：

sudo dpkg --audit
systemctl --failed
timedatectl

dpkg --audit 没有输出、systemctl --failed 显示 0 个失败单元，通常说明基础状态正常。如果时区不正确，可执行：

sudo timedatectl set-timezone Asia/Shanghai

日志较多时可以按需清理旧日志：

sudo journalctl --vacuum-time=14d

这一阶段不安装 Node.js、额外 Python、编译器或具体项目依赖。先把系统基线稳定下来，之后再给每个项目建立独立环境，问题会少很多。

三、设置 WSL 2 的资源上限

在 Windows 用户目录创建：

%UserProfile%\.wslconfig

本机使用的配置如下：

# Global WSL 2 settings for this Windows user.
[wsl2]
memory=32GB
processors=16
swap=8GB
networkingMode=mirrored
dnsTunneling=true
autoProxy=true
firewall=true

[experimental]
autoMemoryReclaim=gradual
sparseVhd=true

保存后执行：

wsl --shutdown

重新进入 Ubuntu，配置才会完整生效。

几个容易误解的点：

  • memory=32GB 是最大可用内存，不是 WSL 一启动就预占 32 GB；
  • processors=16 是 WSL 虚拟机可使用的逻辑处理器上限；
  • swap=8GB 也是容量上限，空闲时不会持续占用 8 GB 物理内存；
  • autoMemoryReclaim=gradual 会逐步回收 Linux 文件缓存；
  • sparseVhd=true 会让新建的 WSL 虚拟磁盘默认采用稀疏模式。

对于 16 GB 内存的电脑，可以从 memory=8GB、processors=4、swap=2GB 开始；如果同时运行 Docker、仿真或大型编译，再按实际峰值增加。所有字段含义以 Microsoft 的 .wslconfig 文档 为准。

生效后可在 Ubuntu 中检查：

nproc
free -h
swapon --show

四、使用镜像网络，并复用 Windows 系统代理

Windows 11 22H2 及以上支持 networkingMode=mirrored。它改善了 VPN、IPv6、组播和 Windows/WSL 双向 localhost 访问，详情见 WSL 网络文档。

配置中的三个相关选项分别负责：

  • networkingMode=mirrored：镜像 Windows 网络接口；
  • dnsTunneling=true：让 WSL 通过 Windows 处理 DNS；
  • autoProxy=true：读取 Windows 的 HTTP 代理信息。

如果 Clash 一类客户端已经设置了 Windows 系统代理，WSL 启动时通常可以同步代理环境。可以这样检查变量是否存在：

env | grep -i proxy
curl -I https://github.com

代理配置在 WSL 已启动后发生变化时，执行一次 wsl --shutdown 再重启最省事。不要把本机代理端口硬编码进公开脚本，因为不同设备和代理客户端的端口可能不同。

Windows 如何访问 WSL 中的服务

在 WSL 中启动测试服务：

python3 -m http.server 8080 --bind 127.0.0.1

然后在 Windows 浏览器访问：

http://localhost:8080

镜像网络下，绑定 127.0.0.1 就能满足本机访问；--bind 0.0.0.0 不是 Windows 访问的必要条件。只有确实需要监听全部 Linux 网络接口或向局域网提供服务时，才考虑 0.0.0.0，同时配置好 Windows/Hyper-V 防火墙。

五、把 Linux 项目放在 Linux 文件系统

WSL 中有两个看起来相似、实际完全不同的位置：

/home/<user>                  # Linux 自己的 ext4 文件系统
/mnt/c/Users/<user>           # 挂载进来的 Windows C 盘

如果项目主要通过 Linux 工具编译、安装依赖和运行测试，建议放在：

mkdir -p ~/workspace ~/.local/bin
cd ~/workspace

不要默认放到 /mnt/c/Users/<user>/...。跨文件系统的大量小文件访问通常更慢，还可能遇到权限、大小写、符号链接和文件监听差异。Microsoft 同样建议 Linux 命令行项目优先存放在 WSL 文件系统，参见 跨文件系统工作说明。

Windows 仍然可以通过资源管理器访问：

\\wsl$\Ubuntu\home\<user>\workspace

也可以在 WSL 当前目录直接执行：

explorer.exe .

六、让 WSL Git 复用 Windows Credential Manager

如果 Windows 已安装 Git for Windows，并且已经通过 Git Credential Manager（GCM）登录 GitHub，WSL Git 可以直接调用 Windows 侧的 GCM。这样 Windows 与 WSL 共用同一套安全凭证，不必在 Linux 中再保存一份 Personal Access Token。

Git for Windows 的默认 GCM 路径通常是：

C:\Program Files\Git\mingw64\bin\git-credential-manager.exe

如果安装位置不同，应先在 Windows 中找到实际路径，再转换成对应的 /mnt/c/... 路径。在 WSL 中配置所有仓库共用：

git config --global credential.helper \
  "/mnt/c/Program\ Files/Git/mingw64/bin/git-credential-manager.exe"

如果只希望当前仓库使用，进入仓库后执行同一命令，但去掉 --global。验证配置来源和私有仓库访问：

git config --show-origin --get credential.helper
git remote -v
git fetch

git fetch 没有认证错误即表示接入成功；远程没有更新时，它通常不会输出内容。还要注意：

  • user.name 和 user.email 只是提交作者信息，不是登录凭证；
  • GCM 获取的令牌仍保存在 Windows Credential Manager，WSL 只是通过互操作调用；
  • 该方式用于 HTTPS 远程地址；SSH 地址应单独配置 SSH 密钥；
  • 不要把 Personal Access Token 写进 remote URL、Shell 脚本或 Git 配置。

具体机制与其他安装路径见 Git Credential Manager 的 WSL 官方说明。

七、最终验收清单

最后依次检查：

# 系统
cat /etc/os-release
uname -r
ps -p 1 -o comm=

# 资源
nproc
free -h
swapon --show

# 健康
sudo dpkg --audit
systemctl --failed

# 网络
getent hosts github.com
curl -I https://github.com

# Git（在 Git 仓库中）
git config --get credential.helper
git fetch

PowerShell 中再确认：

wsl --version
wsl --list --verbose

到这里，WSL 的“地基”就完成了：系统干净、资源有上限、内存按需使用、网络和代理路径明确、项目目录也选对了。下一步再按项目需要安装独立的 Python、Node.js、Docker 或机器人开发环境，而不是污染 Ubuntu 的系统运行时。

原文链接：https://www.ssssmy.com/blog/wsl2-init-performance-network-filesystem