WSL 2 評測：Windows 上的 Linux
架構改變帶來一個必須牢記的效能特性：檔案放在哪裡，決定跑得快不快。
WSL 2 的 Linux 檔案系統（/home、/etc 等）實際上是存放在一個名為 ext4.vhdx 的虛擬硬碟檔案中，由 Linux 核心原生管理，存取速度極快。但當你透過 /mnt/c/ 存取 Windows 磁碟時，9P 協定（較新版本已改用 virtio-9p 的改良實作）必須在 VM 與 Windows 主機之間搬移資料，效能明顯下滑。反過來說，若你用 Windows 的編輯器去開啟 \\wsl$\ 路徑下的檔案，也會有類似問題。
實務結論很簡單：Linux 專案就放在 Linux 檔案系統裡，用 WSL 內的編輯器或 VS Code Remote 來編輯，不要放在 /mnt/c 底下。這一點在後面效能實測章節還會用數據再強調一次。
安裝與環境建置實測
WSL 2 的安裝流程在近幾年簡化到近乎無腦，但仍有幾個細節值得注意，特別是對於企業環境或老舊硬體。
系統需求與前置準備
執行 WSL 2 需要以下的基礎條件：
CPU 需支援並在 BIOS／UEFI 中啟用虛擬化技術（Intel VT-x 或 AMD-V）。
建議至少 8 GB 記憶體；若同時要跑 Docker 與 IDE，16 GB 會舒適許多。
值得注意的是，WSL 2 使用的「虛擬機平台」與「Windows Hypervisor Platform」這兩個選用功能必須開啟。若你同時使用 VMware Workstation 或 VirtualBox，近代版本已能與 Hyper-V 共存，但效能可能略有折損，這點在重度虛擬化使用者身上需要納入考量。
一行指令安裝流程
從 Windows 10 2004 之後，安裝 WSL 已經簡化為單一指令。以系統管理員身分開啟 PowerShell 或 Windows Terminal，輸入：
wsl --install
這行指令會自動啟用所需的 Windows 功能、下載最新的 WSL 核心、設定 WSL 2 為預設版本，並安裝 Ubuntu 作為預設發行版。完成後重新啟動電腦，系統會引導你建立 Linux 使用者帳號與密碼。
若你想指定其他發行版，可以先查詢清單：
wsl --list --online
wsl --install -d Debian
其他常用管理指令包括：
wsl --list --verbose：列出所有已安裝發行版及其 WSL 版本與狀態。wsl --set-version Ubuntu 2：將指定發行版切換到 WSL 2。wsl --set-default-version 2：設定新安裝發行版的預設版本。wsl --update：更新 WSL 核心與相關元件。
wsl --shutdown：強制關閉所有執行中的實例，常用於清理資源或套用設定變更。發行版選擇與初始設定
官方商店提供的發行版相當齊全，包含 Ubuntu、Debian、Kali Linux、openSUSE、AlmaLinux、Oracle Linux 等。若你在意套件新舊，Ubuntu LTS 是最穩妥的選擇；若你需要滲透測試工具，Kali 的一鍵安裝非常方便；若你模擬企業環境，AlmaLinux 或 Rocky Linux 更貼近 RHEL 生態。
首次進入系統後，建議立刻執行標準的更新流程：
sudo apt update && sudo apt upgrade -y接著可以考慮設定 /etc/wsl.conf 來調整一些進階行為，例如啟用 systemd、調整預設使用者、關閉 Windows 路徑自動附加等。以下是一個常見的範例設定：
[boot]
systemd=true
[interop]
appendWindowsPath=false
[automount]
options = "metadata,umask=22,fmask=11"
其中 systemd=true 對需要 systemctl 管理服務的開發者尤其重要，這是近兩年 WSL 最受歡迎的改進之一。
效能實測：WSL 2 到底快不快？
網路上關於 WSL 2 效能的討論常流於片面，有人說「比原生慢」，有人說「幾乎無感」。實際上，效能高度取決於你的工作負載類型與檔案存放位置。以下分幾個面向來談。
跨檔案系統 I/O 效能
這是 WSL 2 最容易被詬病的地方。當你從 WSL 內存取 /mnt/c 的檔案時，每一次檔案操作都要跨越 VM 邊界，經過 9P 或 virtio 通道傳輸。社群實測普遍顯示，小檔案的大量隨機讀寫（例如 git status、npm install、composer install）效能可能只有原生的三分之一到五分之一，有時候甚至更糟。
反過來說，同樣的操作若在 /home/user/project 這種 Linux 原生路徑下執行，效能幾乎與原生 Linux 無異。因此這個「缺點」某種程度是可以完全規避的——只要養成「Linux 專案放 Linux 磁碟」的習慣即可。
以下是一個粗略的效能對照示意（數值為相對感受，非絕對基準）：
操作情境
相對效能感受
建議
Linux 路徑下的大量小檔案操作
接近原生 Linux
推薦日常使用
/mnt/c 路徑下的大量小檔案操作
明顯偏慢
盡量避免
Linux 路徑下的大檔案循序讀寫
良好
可放心使用
跨系統的單一檔案複製
可接受
批次處理較佳
編譯與資料庫效能
在 CPU 密集與記憶體密集的工作負載上，WSL 2 的表現相當亮眼。由於使用的是真實 Linux 核心，且 CPU 是原生執行（透過 Hyper-V 的硬體輔助虛擬化），編譯大型專案的效能通常介於原生 Linux 的 85% 到 98% 之間，視專案 I/O 比重而定。
資料庫方面，PostgreSQL、MySQL／MariaDB、Redis、MongoDB 在 WSL 2 上都能順利運行，且效能對開發用途而言完全足夠。過去在 WSL 1 時代常見的記憶體管理異常、inotify 事件遺漏等問題，在 WSL 2 上基本已不成問題。若有特別需求，也可以透過 .wslconfig 調整分配給 WSL 的記憶體與處理器核心數：
[wsl2]
memory=8GB
processors=4
swap=2GB
把這個檔案放在 Windows 使用者家目錄下（C:\Users\你的帳號\.wslconfig），執行 wsl --shutdown 後重新啟動即可生效。這對記憶體有限或需要精確控制資源的開發者非常實用。
GPU 與圖形應用
WSL 2 支援 GPU 直通（GPU Paravirtualization），NVIDIA、AMD、Intel 都有相應的驅動支援。這代表你可以在 WSL 內執行 CUDA 程式、訓練小型模型、跑 PyTorch 與 TensorFlow，不需額外設定複雜的環境。對資料科學與機器學習開發者而言，這是極具吸引力的功能。
圖形介面方面，Windows 11 內建 WSLg，基於 Wayland 與 XWayland，可直接執行 GUI 應用程式，視窗會以原生 Windows 視窗的形式出現，無需額外安裝 X Server。這讓你能在 WSL 內跑 GIMP、Inkscape、甚至完整的桌面應用，體驗相當流暢。
開發者體驗實測
技術規格是一回事，日常順不順手又是另一回事。WSL 2 真正讓開發者「回不去」的，是它與 Windows 生態的深度整合。
VS Code Remote 整合
Visual Studio Code 的「Remote - WSL」擴充功能，是 WSL 2 體驗的核心。安裝後，你可以在 WSL 內執行 code .，VS Code 便會以「遠端模式」開啟該目錄。此時編輯器介面跑在 Windows，但檔案存取、終端機、擴充功能（例如 Python、Go、Rust 的語言伺服器）全都跑在 WSL 內。
這種架構的好處顯而易見：你享受到 Windows 的圖形效能與輸入體驗，同時擁有 Linux 的開發環境。IntelliSense、除錯、測試執行、終端機全部無縫整合，且完全避開了跨檔案系統的效能問題。對大多數開發者來說，這套組合已經是當今 Windows 上最舒適的開發工作流。
Docker Desktop 與容器化開發
Docker Desktop 在 Windows 上有兩種後端選擇：Hyper-V 與 WSL 2。選擇 WSL 2 後端時，Docker 引擎實際運行在 WSL 的 VM 內，容器啟動速度更快，記憶體佔用更低，且與 WSL 內的檔案系統共享更方便。這項整合讓 Windows 上的容器開發體驗大幅提升，許多原本得靠 Mac 或 Linux 的工作流程，如今在 Windows 上也能順暢執行。
若不想安裝 Docker Desktop，也可以在 WSL 內直接安裝 Docker Engine，或使用 Podman 這類無守護程序的替代方案。對於重視授權成本或偏好純 CLI 的使用者，這是值得考慮的路線。
終端機與 Shell 環境
Windows Terminal 搭配 WSL 2，是目前 Windows 上最接近 iTerm2 體驗的組合。支援分頁、分割窗格、GPU 加速渲染、自訂字型與配色、以及完整的 Unicode 與圖示顯示。搭配 zsh、Oh My Zsh、Starship 或 Fisher 等提示字元框架，可以打造出高度個人化的工作環境。
Shell 之間也能互相呼叫，例如在 PowerShell 中執行 wsl ls -la，或在 WSL 中執行 powershell.exe Get-Process，這種互通性在撰寫自動化腳本時非常方便。
WSL 2 的網路與系統整合
網路是 WSL 2 相對 WSL 1 變化較大的部分，也是使用者較常遇到疑惑的地方。
網路模式與連接埠轉發
WSL 2 預設使用 NAT 模式，WSL 內的服務會有一個獨立的虛擬網路介面與 IP。Windows 主機預設能透過 localhost 存取 WSL 內監聽的服務，這得益於自動的連接埠轉發。不過在早期版本中，這個轉發偶爾會失效，需要手動以 netsh 設定，或重啟 WSL 實例。
若你需要讓區域網路內的其他裝置存取 WSL 內的服務，NAT 模式會帶來一些麻煩，因為轉發僅限於本機。此時可以考慮使用 mirrored 網路模式（在 Windows 11 22H2 之後支援，透過 .wslconfig 設定 networkingMode=mirrored），讓 WSL 直接共用 Windows 的網路介面，存取行為更接近原生。
WSLg 圖形化介面
Windows 11 內建的 WSLg 是另一個殺手級功能。它包含一套 Wayland 合成器、XWayland 相容層，以及 PulseAudio 音訊支援，讓你能直接執行 Linux GUI 程式，視窗與選單會整合進 Windows 的工作列與剪貼簿。這對於需要使用 Linux 專屬工具（如某些 CAD、EDA、資料視覺化套件）的使用者來說，省去了過去架設 X Server 的繁瑣步驟。
WSL 2 的缺點與限制
再好的工具也有邊界，誠實面對限制才能做出正確選型。
/mnt/c 的存取效能始終是痛點，且短期內難有根本性改善。wsl --shutdown。近年已有改善，但仍建議在 .wslconfig 中設定上限。WSL 2 vs 虛擬機 vs 雙系統：該怎麼選？
這三者並非互斥，許多資深開發者其實是混著用的。以下提供一個實務導向的判斷框架。
需求情境
建議方案
理由
日常後端開發、CLI 工具、Git 工作流
WSL 2
啟動快、整合好、資源佔用低
需要完整桌面環境測試
虛擬機
WSLg 仍不適合驗證完整桌面行為
需要測試核心模組、自訂核心
虛擬機
WSL 核心由微軟維護，不易替換
追求極致效能與原生體驗
雙系統
無虛擬化損耗，硬體完全直通
機器學習與 GPU 運算
WSL 2 或雙系統
WSL 2 的 GPU 直通已足夠應付多數場景
簡單來說，WSL 2 的定位是「90% 的 Linux 開發需求，用 10% 的成本解決」。剩下那 10% 的極端場景，才需要動用虛擬機或雙系統。
實用技巧與疑難排解
以下整理幾個實戰中累積的經驗，能省下不少摸索時間。
/mnt/c，改用 code . 在 WSL 內開啟，效能與體驗都會好上一個檔次。.wslconfig 控制資源：避免 WSL 吃掉過多記憶體，尤其在 16 GB 以下的機器上格外重要。ext4.vhdx：刪除檔案後虛擬硬碟不會自動縮小，可用 wsl --manage <發行版> --set-sparse true 或手動掛載後執行 fstrim 來回收空間。wsl --export 與 wsl --import 能將整個發行版打包成 tar 檔，換機或重置時非常好用。wsl.conf 設定 systemd=true，即可使用 systemctl 管理服務，貼近一般 Linux 使用習慣。wsl --shutdown 後重開就能解決。結語：誰適合用 WSL 2？
經過這番實測與分析，WSL 2 的評價可以用一句話總結：它是 Windows 平台上最成功的「妥協產物」，而且妥協得極為漂亮。
如果你是後端工程師、資料科學家、DevOps 工程師、或是任何需要 Linux 工具鏈的開發者，而你的日常工作又高度依賴 Windows 生態（Office、Teams、企業內部系統、特定商業軟體），那 WSL 2 幾乎是唯一合理的解答。它讓你不必在「換系統」與「忍受不便」之間二選一。
如果你追求的是絕對效能、完整桌面體驗、或需要深入核心層級的實驗，那傳統虛擬機或雙系統仍有其不可取代之處。但對於絕大多數開發者而言，WSL 2 已經把「在 Windows 上寫 Linux 程式」這件事，從一件苦差事變成了理所當然的日常。
從 WSL 1 到 WSL 2，微軟花了數年時間，把一個原本被譏為「半調子」的功能，打磨成足以讓 Mac 使用者羨慕的開發環境。這或許也是近年微軟開發者策略轉向最成功的註腳之一。對還在觀望的人來說，現在正是嘗試的最佳時機——一行指令，就能開始。
整體評價：架構設計 9／10、開發體驗 9／10、效能表現 8／10、相容性 9／10、學習曲線 9／10。綜合推薦指數：9.0／10，強烈推薦給所有在 Windows 上工作的開發者。