WSL2 on kenji.blog

Hyper-V vs WSL2：Windows 上的虛擬化技術比較

Sun, 13 Sep 2026 07:00:00 +0900

1. 簡介：Windows 中虛擬化的演進

在過去的幾十年裡，Windows 平台上的虛擬化技術經歷了巨大的演進。過去，第三方 Type 2 Hypervisor（例如 VMware Workstation 或 VirtualBox）曾是主流，但自從微軟在 Windows Server 2008 中引入「Hyper-V」以來，Type 1 Hypervisor 也被內建於作為桌面作業系統的 Windows 10/11 中。

近年來，在開發者中最受矚目的是「WSL2 (Windows Subsystem for Linux 2)」。有別於 WSL1 依賴系統呼叫的轉換 (translation)，WSL2 採用了應用 Hyper-V 技術的「輕量級公用程式虛擬機 (Lightweight Utility VM)」，實現了完全的 Linux 相容性與飛躍性的效能提升。

本文將針對這兩項強大的虛擬化技術——功能齊全的「Hyper-V」與專注於開發者體驗的「WSL2」，就其架構、效能（CPU、記憶體、磁碟 I/O）、網路設定，以及最適合的使用案例，伴隨深度的技術細節進行徹底的比較與解說。

2. Hypervisor 的基礎理論與架構比較

要理解虛擬化技術，不可或缺的是 Hypervisor（虛擬機器監視器: VMM）的類型分類。

2.1. Type 1 與 Type 2 Hypervisor 的差異

Hypervisor 是一個抽象化硬體存取，並允許多個作業系統（客體作業系統）在單一實體機器上同時執行的軟體層。

Type 1（裸機型）: 直接在硬體上執行。不存在主機作業系統的概念（嚴格來說可能存在具有特權的管理作業系統），擁有極低的額外負擔 (overhead)，提供高效能與安全性。例如：Hyper-V、VMware ESXi、Xen。
Type 2（主機型）: 作為主機作業系統（例如 Windows 或 macOS）上的應用程式執行。所有的硬體存取都必須經過主機作業系統，因此額外負擔較大。例如：VMware Workstation、Oracle VirtualBox。

Windows 的 Hyper-V 是純粹的 Type 1 Hypervisor。啟用 Hyper-V 後，實際上使用者平常操作的 Windows 作業系統本身，也會改在一個被稱為「根分割區 (Root Partition)」的特殊虛擬機器中運作。

2.2. Hyper-V 的架構細節

Hyper-V 的架構採用微核心設計，並基於被稱為分割區 (Partition) 的邏輯隔離單位。

graph TD
A["硬體 (CPU, RAM, 磁碟, NIC)"] --> B["Windows Hypervisor (Ring -1)"]
B --> C["根分割區 (Windows OS)"]
B --> D["子分割區 1 (Windows VM)"]
B --> E["子分割區 2 (Linux VM)"]
C --> F["VMBus (虛擬機器匯流排)"]
D --> F
E --> F
C --> G["VID (虛擬化基礎架構驅動程式)"]
C --> H["VMWP.exe (工作處理程序)"]

Windows Hypervisor: 在 CPU 最高特權層級的狀態（Ring -1 或 VMX Root Mode）下運作，僅負責記憶體的分配與 CPU 的排程。不包含裝置驅動程式。
根分割區 (Root Partition): 運作主機 Windows 作業系統的分割區。擁有所有的裝置驅動程式，並直接控制硬體。同時提供管理子分割區的功能（例如 WMI 提供者或 VMWP.exe 等）。
子分割區 (Child Partition): 運作客體作業系統的分割區。不允許直接存取硬體，而是透過被稱為「VMBus」的邏輯記憶體共用匯流排，向根分割區傳送 I/O 請求（綜合 I/O / Synthetic I/O）。

2.3. WSL2 與 Lightweight Utility VM 的機制

WSL2 利用了與 Hyper-V 相同的 Type 1 Hypervisor 基礎技術，但使用的是被稱為「虛擬機器平台 (Virtual Machine Platform: VMP)」的子集功能，與全功能的 Hyper-V 虛擬機器不同。

WSL2 所採用的「輕量級公用程式虛擬機 (Lightweight Utility VM)」，完全排除了傳統 VM 所擁有的舊有硬體模擬（例如虛擬 BIOS 或虛擬主機板等）。

graph TD
A["Windows 主機作業系統 (使用者空間)"]
B["NTFS 檔案系統"]
C["9P 協定伺服器 (Plan 9)"]
D["輕量級公用程式虛擬機 (Linux 核心)"]
E["ext4.vhdx (虛擬磁碟)"]
F["Linux 使用者空間 (WSL2 發行版)"]
A --> C
C -->| 跨作業系統檔案共用 | D
D --> E
D --> F

WSL2 最大的特色在於啟動速度快以及與主機作業系統的無縫整合。不到幾秒鐘內即可啟動 Linux 核心，並且透過 Plan 9 的 9P 網路檔案系統協定來存取 Windows 端的檔案系統 (NTFS)。

3. 效能徹底分析：運算資源與 I/O

虛擬機器的效能可以表示為 CPU、記憶體及磁碟 I/O 等各個元件的額外負擔總和。

3.1. CPU 與內容切換額外負擔

Hyper-V 與 WSL2 均使用了硬體輔助虛擬化 (Intel VT-x / AMD-V)。CPU 指令基本上以原生速度執行，但在執行特權指令或進行 I/O 處理時會發生稱為「VM Exit」的中斷，並向 Hypervisor 進行內容切換。

此時的 CPU 額外負擔 $T_{overhead}$ 可以用以下的數學模型來表示：

$$ T_{overhead} = \sum_{i=1}^{N} (t_{vm\_exit} + t_{hypercall\_process} + t_{vm\_entry}) $$

在此：

$N$: 單位時間內發生 VM Exit 的次數
$t_{vm\_exit}$: 從客體切換至 Hypervisor 的時間
$t_{hypercall\_process}$: 透過 VMBus 進行 I/O 處理或中斷的處理時間
$t_{vm\_entry}$: 從 Hypervisor 返回至客體的時間

WSL2 因為沒有舊有模擬，所以 $t_{hypercall\_process}$ 被極度優化並保持在極小的值。因此，在純粹的 CPU 運算（例如編譯核心或機器學習模型的推論）方面，與裸機環境相比，效能下降程度也控制在幾個百分比以內。

3.2. 記憶體分配的機制

在記憶體管理方法上，兩者有著明確的設計理念差異。

Hyper-V (Dynamic Memory): 根分割區會根據客體 VM 的記憶體需求，動態地分配與回收記憶體。然而，在客體作業系統內被保留作為分頁快取的記憶體，除非系統資源緊缺，否則通常很難被釋放。
WSL2 (動態記憶體回收): WSL2 擁有獨特的機制，會定期將 Linux VM 內不再需要的記憶體（包含快取）返還 (Reclaim) 給 Windows 主機。早期的 WSL2 曾經有 Linux 的分頁快取耗盡 Windows 記憶體的問題（Vmmem 處理程序肥大化），但目前已透過核心修補程式獲得改善。

3.3. 磁碟 I/O 特性（VHDX vs ext4.vhdx）

在虛擬機器效能中最容易成為瓶頸的就是磁碟 I/O。

I/O 的延遲 $L_{total}$ 的計算方式如下：

$$ L_{total} = L_{guest\_fs} + L_{vmbus} + L_{host\_fs} + L_{physical\_disk} $$

在 Hyper-V 的情況：一般的 Hyper-V 客體使用 VHDX 格式的虛擬磁碟。從客體作業系統內的檔案系統（ext4 或 NTFS）發出的 I/O 請求，會通過 VMBus 的區塊裝置儲存驅動程式 (storvsc)，並在 Windows 端的 NTFS 上作為對 VHDX 檔案的存取來處理。

在 WSL2 的情況： WSL2 的 Linux 發行版運作於建立在專用的 ext4.vhdx 檔案內的原生 ext4 檔案系統之上。在 Linux 內部的檔案操作（例如 ~ 目錄內），可發揮與上述 Hyper-V 同等的原生效能。然而，當從 WSL2 的 Linux 存取 Windows 端的檔案（如 /mnt/c/ 等）時，或者反向操作時，處理方式則有很大的差異。這種跨 OS 存取會使用 9P (Plan 9 File System Protocol)。

$$ L_{cross\_os} = L_{9p\_client} + L_{socket\_transfer} + L_{9p\_server} + L_{ntfs} $$

透過這個 9P 協定的存取，其序列化處理的額外負擔非常大，在需要大量讀寫小檔案的用途中（例如：在 Windows 端目錄下的 Node.js 專案執行 npm install 或 Git 操作），效能會顯著下降（有時會產生 10 倍以上的延遲）。因此，使用 WSL2 時，務必將專案檔案放置在 Linux 的原生檔案系統（~/ 目錄下），這是基本鐵則。

4. 網路結構：NAT、Default Switch、Bridged

網路功能的彈性是 Hyper-V 與 WSL2 的一大差異。

4.1. WSL2 的網路 (NAT 基礎)

WSL2 的網路預設為使用了 Hyper-V 虛擬交換器技術的「NAT（網路位址轉換）」架構。 Linux VM 會自動被分配與 Windows 主機不同的私有 IP 位址（例如：172.20.x.x）。系統內建了從 Windows 主機透過 localhost 轉發至 WSL2 內啟動的服務（連接埠）的機制，開發者可以在不需特別意識網路的情況下測試網頁伺服器等。

近年來，WSL2 在預覽版中引入了稱為「Mirrored 模式」的新網路模式。這提升了對 IPv6 的支援與 VPN 連線的相容性（可透過 .wslconfig 進行設定）。

4.2. Hyper-V 的虛擬交換器 (Virtual Switch)

Hyper-V 能夠建立企業級的高階網路架構。透過「虛擬交換器管理員」，主要提供 3 種模式：

外部 (External): 將主機機器的實體 NIC 綁定至虛擬交換器，讓客體 VM 直接加入實體網路（橋接連線）。VM 會從 DHCP 伺服器取得與實體網路相同子網路的 IP。
內部 (Internal): 僅允許主機作業系統與 VM 之間，以及 VM 彼此之間的通訊。無法直接連線至外部網路。
私人 (Private): 僅允許 VM 彼此之間的通訊，阻斷與主機作業系統的通訊。用於建立隔離的驗證環境。

4.3. 透過 PowerShell 建立進階的 Hyper-V 網路

在開發或測試環境中，如果想為 VM 建立自訂的 NAT 網路，可以使用 PowerShell 進行詳細的控制。以下是建立內部虛擬交換器，並在其中設定 NAT 以提供 VM 網際網路存取的指令碼範例。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 1. 建立內部虛擬交換器
$SwitchName = "HyperV-NatSwitch"
New-VMSwitch -SwitchName $SwitchName -SwitchType Internal

# 2. 在主機端的虛擬 NIC 設定 IP 位址 (作為閘道器的 IP)
$GatewayIP = "192.168.100.1"
$NetPrefix = 24
$InterfaceAlias = "vEthernet ($SwitchName)"
New-NetIPAddress -IPAddress $GatewayIP -PrefixLength $NetPrefix -InterfaceAlias $InterfaceAlias

# 3. 設定 NAT 網路
$NatName = "HyperV-NatNetwork"
$NatSubnet = "192.168.100.0/24"
New-NetNat -Name $NatName -InternalIPInterfaceAddressPrefix $NatSubnet

# 確認用命令
Get-NetNat

透過此設定，藉由手動將指定的 Hyper-V 客體設定為 192.168.100.x 的 IP 與閘道器 192.168.100.1，即可建立能經由主機與外部通訊的專屬 NAT 網段。

5. 使用案例與實用的選擇指南

根據至今為止對於架構與效能差異的了解，我們將定義在何種情況下應採用哪種技術。

5.1. 應選擇 WSL2 的情境

WSL2 是專為「提升開發者生產力」而設計的。最適合以下用途：

網頁開發與雲端原生開發: 使用 Docker Desktop（WSL2 後端）或 Podman 的容器開發。
使用 Linux 專用工具: 日常使用 bash、grep、awk、sed，或是 Linux 平台的 GCC 或 Clang 編譯器時。
GUI 應用程式 (WSLg): 想在 Windows 桌面環境上無縫執行 Linux 的 X11/Wayland 應用程式時。
機器學習與 AI 開發: 利用 GPU 穿透功能（NVIDIA CUDA on WSL）來進行 TensorFlow 或 PyTorch 的高速訓練。

注意事項: 如果想對核心進行細微的客製化，或是要建立強烈依賴 systemd 的複雜服務（目前雖已支援 systemd，但預設為停用或受限）時，可能會受到限制。

5.2. 應選擇 Hyper-V 的情境

Hyper-V 的目的在於「基礎架構的虛擬化與完全隔離」。在以下用途中將是必不可少的：

執行 Windows VM: 當需要將不同版本的 Windows（如 Windows Server 或舊版 Windows 10 等）作為測試環境執行時。
巢狀虛擬化 (Nested Virtualization): 想在虛擬機器中進一步執行虛擬機器（Hyper-V 或 KVM）時。這對於基礎設施工程師的驗證環境是不可或缺的。
進階網路需求: 需要嚴格控制網路架構時，例如外部橋接連線（加入同一個 LAN）、VLAN 標記、指派多個 NIC 等。
快照（檢查點）: 儲存 VM 在特定時間點的狀態，並能隨時瞬間還原的功能。對於軟體的破壞性測試或惡意軟體分析等非常有用。
固定的資源分配: 想嚴格固定 CPU 核心數或記憶體量，將對主機作業系統的影響降至最低時。

6. 基於數學模型的 I/O 吞吐量探討 (附錄)

身為系統工程師，在釐清兩者的 I/O 效能極限時，理論上掌握吞吐量 $S$ 與區塊大小 $B$ 的關係是很重要的。

資料傳輸的吞吐量 $S$ 為單位時間內的資料傳輸量，其模型如下：

$$ S(B) = \frac{B}{L_{setup} + \frac{B}{R_{max}}} $$

$B$: 區塊大小 (Bytes)
$L_{setup}$: 伴隨 I/O 請求的設定與內容切換而來的固定延遲
$R_{max}$: 複製或裝置傳輸中硬體的最大頻寬

在透過 WSL2 的 9P 協定存取檔案時，這個 $L_{setup}$ 會變得非常大（因為 Socket 通訊與協定的序列化/反序列化）。因此，當區塊大小 $B$ 較小（大量讀寫數 KB 左右的小檔案）時，分母中的 $L_{setup}$ 影響將佔主導地位，吞吐量 $S$ 會急遽下降。相反地，透過 Hyper-V 的 VMBus 進行 VHDX 存取時，由於 $L_{setup}$ 已被最佳化至接近硬體中斷的程度，所以即使是小規模的區塊也能維持高 IOPS。

這個數學現實成為了「在 WSL2 中絕對不能將專案檔案放在 Windows 端」這項最佳實踐的邏輯依據。

7. 總結：共存的兩種虛擬化技術

Hyper-V 與 WSL2 並不是哪一方比較優秀的問題，而是**「目的不同的兩種解決方案」**。

WSL2 打破了 Windows 這個作業系統的框架，是為了將 Linux 的生態系統無縫且高速地傳遞到 Windows 使用者手中而生的「最佳整合工具」。稱其為開發者專用的終極 CLI 環境一點也不為過。
Hyper-V 則是將企業資料中心培育出的強大隔離性與管理能力帶入桌面的「正統 Hypervisor」。在網路建構、Windows 作業系統測試、基礎設施環境模擬等方面無可匹敵。

在現代的 Windows 環境中，這兩項技術並不是勢均力敵的競爭者，而是在同一個 VM 平台上完美共存。透過根據用途適材適所地運用，Windows 將會成為世界上最強大且具彈性的工程工作站吧。

WSL2（Windows Subsystem for Linux）的終極開發環境設定指南

Sat, 12 Sep 2026 23:00:00 +0900

在 Windows 上提供原生 Linux 開發環境的「WSL2（Windows Subsystem for Linux 2）」已成為現代軟體開發中不可或缺的工具。然而，維持預設狀態使用，與了解架構並進行適當的調校相比，兩者在效能和開發體驗上會有天壤之別。

本文將從 WSL2 核心的架構解說開始，徹底解說能將效能發揮到極致的設定、建構舒適的終端機環境、與 Docker 和 VS Code 的無縫整合，以及進階的網路設定。為了建構專業工程師所追求的「終極開發環境」，我們將以超過一萬字以上的篇幅為您詳細說明所有的步驟。

1. WSL2 的架構與自 WSL1 的進化

為了完全發揮 WSL2 的潛力，首先必須了解其內部結構。第一代 WSL（WSL1）與 WSL2 在 Windows 上執行 Linux 二進位檔案的方法有著根本上的差異。

WSL1：系統呼叫的轉換層

WSL1 採用了將 Linux 的系統呼叫即時轉換（Translation）為 Windows NT API 的機制。由於不使用虛擬機器（VM），這項作法具有資源負擔極小的優點。然而，要完全模擬檔案系統的 I/O 操作等複雜系統呼叫相當困難，特別是在執行 Node.js 的 npm install 或是 Git 的版本庫操作等處理大量小檔案的作業時，會導致效能出現絕望性的下降。

WSL2：輕量級公用程式 VM 與完整的 Linux 核心

WSL2 重新設計了架構，在利用 Hyper-V 架構子集的「輕量級公用程式 VM」 上，直接執行由 Microsoft 建置的真正 Linux 核心。這確保了系統呼叫 100% 的相容性，並透過使用採用 Linux 原生 ext4 檔案系統的虛擬磁碟（VHDX），檔案 I/O 效能與 WSL1 相比有了戲劇性的提升。

以下的 Mermaid 圖表展示了 WSL1 與 WSL2 的結構差異。

flowchart TD
subgraph "Windows 作業系統環境"
A["Windows NT 核心"]
A --> F["NTFS 檔案系統 (C: 磁碟機)"]
end
subgraph "WSL2 架構"
B["Hyper-V Hypervisor"]
B --> C["輕量級公用程式 VM"]
C --> D["Linux 核心 (Microsoft)"]
D --> E["Ubuntu 使用者空間 (glibc, bash 等)"]
D --> G["ext4 虛擬磁碟 (.vhdx)"]
end
A -.->|"Plan 9 (9P) 通訊協定網路檔案共用"| D
style B fill:#f9f,stroke:#333,stroke-width:2px
style D fill:#bbf,stroke:#333,stroke-width:2px

從這個結構中獲得的重要教訓是，「對 Linux 側的檔案（VHDX 內部）存取速度極快，但對 Windows 側的檔案（/mnt/c/）存取因為需要透過 9P 通訊協定而非常緩慢」。專案的原始碼必須一律放置於 WSL 側的主目錄（~）之下。

2. 效能的數學分析：為什麼 WSL2 這麼快？

讓我們試著使用數學模型來定量評估 WSL2 的效能提升。在軟體開發中，最耗時的操作之一就是伴隨大量檔案 I/O 的處理程序（例如：安裝函式庫或建置）。

某個處理程序的總執行時間 $T_{total}$，可以表示為 CPU 運算時間 $T_{compute}$ 與磁碟 I/O 所需時間 $T_{io}$ 的總和。

$$ T_{total} = T_{compute} + T_{io} $$

在 WSL1 的情況下，由於會產生將 Linux 側的操作轉換為 NTFS 操作的負擔，因此 I/O 時間可以用以下模型表示。其中，$n$ 為檔案操作的次數，$t_{ntfs\_syscall}$ 為 Windows 側系統呼叫的執行時間，$t_{trans}$ 為轉換層的負擔。

$$ T_{wsl1\_io} = \sum_{i=1}^{n} (t_{ntfs\_syscall_i} + t_{trans_i}) $$

另一方面，在 WSL2 的情況下，因為核心會直接對 ext4 檔案系統發出 I/O，負擔僅有虛擬化造成的極微小延遲 $t_{virt}$。

$$ T_{wsl2\_io} = \sum_{i=1}^{n} (t_{ext4_i} + t_{virt_i}) $$

在一般的檔案系統中，因為 $t_{ext4} \ll t_{ntfs\_syscall} + t_{trans}$，當 $n$ 非常大（執行數萬到數十萬次的檔案操作）時，WSL1 與 WSL2 的 I/O 時間差距會呈指數級別拉開。

此外，若將虛擬化環境中 CPU 運算負擔的比例設為 $\rho$，在最新的硬體輔助虛擬化（Intel VT-x / AMD-V）下，$\rho \approx 0.01 \sim 0.03$（大約 1% 到 3%）。因此，即使在純粹的運算任務中，也能發揮出毫不遜色於原生 Linux 環境的 $97\% \sim 99\%$ 效能。

3. 安裝與基底建構

在 Windows 10/11 中，WSL2 的安裝變得非常簡單。只要以系統管理員權限開啟 PowerShell，並執行以下指令即可。

1
2
3
4
5
6


# 預設將安裝 WSL2 與 Ubuntu
wsl --install

# 若要指定特定的發行版
# 可透過 wsl --list --online 進行確認
wsl --install -d Ubuntu-24.04

安裝後經過重新啟動，首次啟動時會要求設定 UNIX 的使用者名稱與密碼。這個使用者與 Windows 的使用者是獨立的，僅在 WSL 內部有效。

如果您已經在使用 WSL1，請使用以下指令轉換為 WSL2。

1
2
3
4
5


# 將現有的發行版轉換為 WSL2
wsl --set-version Ubuntu 2

# 將未來新增的發行版預設為 WSL2
wsl --set-default-version 2

4. 資源控制的秘訣：.wslconfig 與 wsl.conf

WSL2 最大的陷阱之一就是「無限制地消耗記憶體（Vmmem 處理程序過度膨脹）」。由於 WSL2 會使用 Linux 核心的分頁快取（Page Cache），每次進行 I/O 操作都會無止盡地耗盡主機（Windows）的記憶體。為了防止這種情況，必須透過設定檔來限制資源。

WSL2 的設定檔分為兩個：會影響整個 Windows 的 .wslconfig，以及會影響各個發行版內部的 wsl.conf。

4.1. .wslconfig (Windows 側)

在 Windows 的使用者設定檔目錄（C:\Users\<使用者名稱>\.wslconfig）建立檔案，並控制配置給 VM 的資源。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# C:\Users\<使用者名稱>\.wslconfig
[wsl2]
# 分配給 VM 的最大記憶體量。建議為主機總記憶體的 50% 到 75% 左右
memory=16GB

# 使用的 CPU 核心數（省略時將使用全部核心）
processors=8

# 交換檔案（Swap file）的大小
swap=8GB

# 交換檔案的儲存位置（如果想節省 C 磁碟機空間的話）
# swapfile=D:\\wsl\\swap.vhdx

# 啟用 localhost 轉發（為了從 Windows 側透過 localhost 存取 WSL）
localhostForwarding=true

# 自動釋放記憶體（僅限 Windows 11）
# 動態釋放分頁快取，防止 Vmmem 過度膨脹
autoMemoryReclaim=dropcache

[experimental]
# Windows 11 22H2 之後可用的進階網路功能
# 藉此可以支援 IPv6，以及讓 WSL 與 Windows 之間共用同一個 IP 位址
networkingMode=mirrored
dnsTunneling=true
firewall=true
autoProxy=true

4.2. wsl.conf (Linux 側)

編輯 WSL 內的 /etc/wsl.conf，以控制發行版專屬的行為。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# /etc/wsl.conf (在 WSL 內部編輯)
[network]
# 停用 WSL 啟動時自動產生的 /etc/resolv.conf
# 如果想設定自訂的 DNS（例如：8.8.8.8）時會很有用
generateResolvConf=false

# 設定自訂的主機名稱
hostname=WSL-DevNode

[automount]
# 掛載 Windows 磁碟機時的設定
enabled=true
options="metadata,uid=1000,gid=1000,umask=022"
# 將 C 磁碟機的掛載點從 /mnt/c 變更為 /c（縮短路徑）
root=/

[boot]
# 啟用 systemd（WSL 0.67.6 之後）
# 藉此，snap 與各種守護行程（如 Docker 等）就能原生執行
systemd=true

[user]
# 預設登入的使用者
default=kenji

為了讓這些設定生效，必須在 PowerShell 執行 wsl --shutdown，完全停止 WSLVM 後再重新啟動。

5. 終極的終端機環境：Zsh + Powerlevel10k

如果繼續使用預設的 bash，生產力將無法提升。結合擁有強大自動補齊功能與高可視性的 Zsh，以及超快速的主題「Powerlevel10k」，來建構最強的命令提示字元（Prompt）。

5.1. 安裝與設定 Windows Terminal

從 Microsoft Store 安裝「Windows Terminal」。開啟 JSON 設定檔（settings.json），將預設設定檔設定為 WSL（Ubuntu），並將字型變更為適合開發的 Nerd Font（例如：HackGen Console NF 或 MesloLGS NF）。

5.2. 安裝 Zsh 與 Oh My Zsh

在 WSL 的終端機執行以下指令。

1
2
3
4
5
6


# 更新套件並安裝 Zsh
sudo apt update && sudo apt upgrade -y
sudo apt install -y zsh git curl

# 執行 Oh My Zsh 安裝指令碼
sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

5.3. 匯入 Powerlevel10k 與外掛程式

匯入能進一步強化 Zsh 的外掛程式（語法凸顯與輸入補齊），以及 Powerlevel10k 主題。

1
2
3
4
5
6
7
8


# Powerlevel10k
git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k

# zsh-autosuggestions
git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

# zsh-syntax-highlighting
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

編輯 ~/.zshrc，啟用主題與外掛程式。

1
2
3
4
5


# ~/.zshrc 的變更點
ZSH_THEME="powerlevel10k/powerlevel10k"

# 新增至外掛程式的陣列中
plugins=(git zsh-autosuggestions zsh-syntax-highlighting)

存檔並執行 source ~/.zshrc 後，就會啟動 Powerlevel10k 的設定精靈（p10k configure）。請依照畫面指示，自訂您喜歡的提示字元（提示字元樣式、是否顯示圖示、要顯示的資訊等）。Git 的分支名稱與狀態、Node.js 的版本、指令的執行時間等將會即時顯示，開發效率將會有飛躍性的提升。

6. VS Code Remote - WSL 的無縫整合

在 WSL2 的開發中，能從安裝在 Windows 側的 IDE（Visual Studio Code）無縫存取 WSL 內檔案的機制就是「Remote - WSL」擴充功能。

架構解說

以下的循序圖展示了 VS Code 是如何與 WSL2 進行通訊的。

sequenceDiagram
autonumber
participant U as "開發者"
participant V as "VS Code UI (Windows)"
participant S as "VS Code 伺服器 (WSL2)"
participant F as "ext4 檔案系統 (WSL2)"
U->>V: "在 WSL 終端機輸入 `code .`"
V->>S: "透過 Vsock 建立 RPC 連線"
Note over V,S: 不使用 TCP/IP，而是使用 Hyper-V Socket 進行通訊
S->>F: "讀取原始碼檔案 / 執行 Linter"
F-->>S: "回傳資料與分析結果"
S-->>V: "將 Language Server 的結果串流至 UI"
V-->>U: "顯示語法凸顯與錯誤"

Windows 側的 VS Code 僅作為一個單純的「精簡型用戶端（UI）」運作，而 Language Server、除錯器（Debugger）、終端機執行等繁重的處理，全都在 WSL 側的「VS Code 伺服器」上進行。這樣一來，不需在 Windows 側安裝 Node.js 或 Python，就能只在 WSL 側保持環境的乾淨。

必備的 VS Code 設定

從 VS Code 的「擴充功能」中安裝 “WSL” (ms-vscode-remote.remote-wsl)。之後，只要在 WSL 的終端機切換至專案目錄，並執行 code .，就能在開啟該目錄的狀態下啟動 Windows 側的 VS Code。

重要的注意事項（換行字元問題）： Windows 與 Linux 的換行字元不同（Windows 是 CRLF，Linux 是 LF）。在 WSL 上進行開發時，請務必將 Git 的 core.autocrlf 設定，以及 VS Code 的檔案預設設定統一為 LF。如果忽略這一點，在執行 Shell Script 或 Docker 容器時將會遇到莫名其妙的錯誤。

1
2


# 在 WSL 側設定 Git 的換行字元
git config --global core.autocrlf input

也在 VS Code 的 settings.json（遠端設定）中新增以下內容。

1
2
3
4


{
 "files.eol": "\n",
 "terminal.integrated.defaultProfile.linux": "zsh"
}

7. Docker Desktop 與 WSL2 Integration 的最佳化

在 WSL2 環境中使用 Docker，主要有兩種方法。

安裝 Docker Desktop for Windows，並啟用 WSL2 整合功能
在 WSL2 內部（如 Ubuntu 等）直接安裝原生的 Docker Engine

方法 1：Docker Desktop（推薦）

由於可以透過 GUI 進行管理，且在 Windows/WSL 之間可以輕鬆透明地存取容器，因此大多情況下推薦使用此方法。從 Docker Desktop 的設定（Settings）中確認以下事項。

勾選 General -> Use the WSL 2 based engine。
勾選 Resources -> WSL Integration -> Enable integration with my default WSL distro，並將要使用的發行版（Ubuntu）的開關切換為開啟。

如此一來，就能從 WSL2 的終端機直接執行 docker 指令，並透過由 Docker Desktop 管理的專屬輕量級 VM（docker-desktop 與 docker-desktop-data）來與 Docker 守護行程進行通訊。

方法 2：直接匯入原生 Docker Engine

如果是受到企業網路的限制（為了避免 Docker Desktop 的收費等），或是想要將效能負擔降到極限，可以在 /etc/wsl.conf 中啟用 systemd 後，將其當作純粹的 Ubuntu 伺服器來安裝 Docker。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# 啟用 systemd 的 WSL2 Ubuntu 上的 Docker 官方安裝步驟摘錄
sudo apt-get update
sudo apt-get install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# 新增版本庫
echo \
 "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
 "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
 sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# 將目前的使用者加入 docker 群組（為了不需 sudo 即可執行）
sudo usermod -aG docker $USER

重新啟動後，systemctl start docker 就能和原生 Linux 環境完全一樣地運作，並發揮高效能。

8. SSH 金鑰的整合：Windows 與 WSL 的無縫驗證

在進行 Git 的 SSH 複製或 SSH 連線至遠端伺服器時，在 Windows 側和 WSL 側分別管理不同的 SSH 金鑰是一件非常麻煩的事。為了兼顧安全性與便利性，可以設定將 Windows 側執行的 SSH 代理（或是 1Password 等密碼管理工具）橋接至 WSL 側。

這裡將解說作為最安全且現代的方法：利用 1Password 的 SSH 代理功能或 Windows 的 OpenSSH Authentication Agent，並使用 npiperelay 或 socat 將其轉發至 WSL2 的 UNIX 網域通訊端（Domain Socket）的方法。

ssh-agent 的通訊端轉發

通常以 Windows 具名管道（Named Pipe）提供的 SSH 代理，必須轉換為 WSL 側的通訊端檔案。利用 wsl-ssh-agent 或是 1Password 提供的功能就可以輕鬆達成。

從 1Password 的設定畫面中啟用「開發者」->「使用 SSH 代理」。接著，在 WSL 側的 ~/.zshrc 或 ~/.bashrc 中加入以下設定，使其在登入時自動綁定通訊端。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 寫入 ~/.zshrc 的內容（使用 1Password SSH Agent 的範例）
export SSH_AUTH_SOCK=$HOME/.ssh/agent.sock
# 當 WSL 啟動時通訊端不存在，或處理程序未綁定時，使用 socat 與 npiperelay 進行轉發
ALREADY_RUNNING=$(ps -aux | grep "[n]piperelay.exe -ei -s //./pipe/openssh-ssh-agent" | wc -l)
if [ $ALREADY_RUNNING -eq 0 ]; then
 if [ -S $SSH_AUTH_SOCK ]; then
 rm $SSH_AUTH_SOCK
 fi
 # 在背景啟動 socat，並將 Windows 側的 Named Pipe 連接至 WSL 側的 UNIX 通訊端
 (setsid socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:"npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork &) >/dev/null 2>&1
fi

※需要事先在 Windows 側安裝 npiperelay.exe 並設定好環境變數路徑。

設定完成後，從 WSL 的終端機執行 ssh-add -l 時，就會顯示在 1Password 或是 Windows 側所註冊的 SSH 金鑰公鑰清單。這樣一來，不需將私鑰檔案複製到 WSL 內，也能安全地通過驗證。

9. 維護：膨脹的 VHDX 最佳化（壓縮）

WSL2 最大的缺點之一是「即使刪除 Docker 映像檔或檔案，Windows 側虛擬磁碟（.vhdx）的檔案大小也不會自動縮小」的規格。長期開發下來，ext4.vhdx 檔案可能會膨脹到數十 GB 到數百 GB。

為了釋放磁碟空間，必須定期從 Windows 側將 VHDX 最佳化（Compact）。

首先，完全關閉 WSL。
1

wsl --shutdown
開啟擁有系統管理員權限的 PowerShell，並執行以下的 diskpart 指令，或是 Hyper-V 模組的 Optimize-VHD 指令（僅限啟用 Hyper-V 時才能使用後者）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 能夠使用 Hyper-V 模組的情況
Optimize-VHD -Path "$env:LOCALAPPDATA\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx" -Mode Full

# 使用 diskpart 的情況
diskpart
# 在以下的提示字元中以互動方式輸入
DISKPART> select vdisk file="C:\Users\<使用者名稱>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx"
DISKPART> attach vdisk readonly
DISKPART> compact vdisk
DISKPART> detach vdisk
DISKPART> exit

定期執行此操作，就能找回被白白消耗的 C 磁碟機空間。

10. 結語

WSL2 已經完全超越了單純只是「在 Windows 上運作的附屬 Linux」的框架，進化成了不亞於 MacOS 或原生 Linux 機器，甚至更強大的開發平台。

藉由套用本次解說的所有設定（透過 .wslconfig 的資源最佳化、透過 Zsh + Powerlevel10k 的終端機強化、透過 VS Code Remote 的透明存取，以及 SSH 整合與 VHDX 的維護），就能完成一個無壓力、高速且安全的「終極開發環境」。

雖然建構環境需要花費一點功夫，但只要設定過一次，未來的工程開發的生產力絕對會有飛躍性的提升。請務必配合自身的專案與喜好，以此指南為基礎，探索更進階的自訂設定。