以往在Windows中跨平臺開發有兩條主流路徑：

方案1：裝WSL。能完整用Linux命令，但需要虛擬機層級開銷，文件互訪、路徑轉換仍有些麻煩；

方案2：裝Git Bash/Cygwin/MinGW。第三方環境，版本雜亂、兼容性參差不齊，部分腳本跑不通。

如今，微軟在Build 2026開發者大會上正式推出適用于Windows系統的Coreutils工具集，將多款主流Linux命令行工具原生集成到Windows平臺中。

該項目基于開源項目uutils開發而成。uutils采用Rust語言重構了GNU核心工具集，具備跨平臺特性。推出這套工具的初衷，是讓開發者在Linux、macOS、原生Windows以及Windows子系統（WSL）之間切換工作環境時，無需改動原有命令行使用習慣。

微軟已在GitHub上架相關軟件包，整合了uutils、傳統核心工具集、文件查找工具集，以及兼容GNU標準的grep程序，最終打包為單一可執行文件對外提供。

Coreutils安裝方式與單文件運行原理

Windows版Coreutils收錄了大量Linux用戶熟知的命令行工具，包括cat、cp、find、grep、hostname、ls、mv、pwd、rm、sleep、tee和uptime等。借助這套工具，簡單文件處理和文本類腳本無需修改，就能直接在Windows上順暢運行。

你可以直接Win+X打開PowerShell，通過WinGet工具執行以下命令完成自動安裝：

winget install Microsoft.Coreutils

微軟并未為每一個命令單獨制作可執行程序，而是統一開發了coreutils.exe，所有工具功能都集成在這一個文件內，通俗地講，類似過去DOS操作系統中的command.com文件。

安裝過程中，程序會為每一條支持的命令創建NTFS硬鏈接，例如ls.exe、cp.exe、cat.exe、rm.exe等。這些鏈接文件全部指向存放于C:\Program Files\coreutils目錄下的主程序coreutils.exe。

當你執行任意一條相關命令時，系統都會加載coreutils.exe，程序再根據調用的命令名稱，啟動對應的工具功能。

這種設計既能讓微軟只維護一個主程序文件，又能保留Linux風格的獨立命令調用形式。因此在使用時，你會看到數十個不同命令名，最終都指向同一個可執行文件。

終端沖突與兼容性

不少Linux命令和Windows命令提示符、PowerShell內置命令重名。微軟為此發布了一份兼容性對照表，詳細說明了各個工具在不同Windows終端中的運行表現。

ls、cat、cp、mv、rm、pwd、sleep、tee等命令均在表格之列。而這些工具能否正常生效，取決于你當前使用的終端類型、系統環境變量PATH的目錄優先級，以及PowerShell的別名配置。

dir、more、paste、whoami等命令并未納入本次工具集，原因是它們和Windows原生命令存在功能沖突。

功能取舍及背后的原因

部分依賴POSIX標準接口的類Unix工具，因Windows系統本身不兼容相關特性，本次并未一同推出，典型包括chmod、chown、chroot、nohup、tty、who等命令。

kill和timeout同樣暫未支持，根源在于Windows不兼容POSIX信號機制。微軟也表示，未來有可能會追加信號相關功能支持。

官方同時提醒，同一命令在Linux和Windows平臺上的運行效果可能存在差異。這類區別主要來自換行符格式、文件權限機制以及POSIX接口兼容度的不同。

推出Windows版Coreutils，是微軟優化開發者體驗、提升Windows開發生態吸引力的舉措。在本屆Build2026大會上，微軟還發布了WSL容器功能，用戶今后可依托原生命令行工具與接口，在Windows上創建、運行和管理Linux容器。

理性看待短板

總的來看，Coreutils依然無法完全替代WSL。

首先，缺失POSIX核心能力。明確砍掉了chmod/chown/kill/nohup 等依賴POSIX權限、進程信號的命令。Windows本身沒有Unix式用戶權限、進程信號體系，這類功能短期內很難補齊。這注定了只適合文件處理、文本篩選、簡單腳本，不適合深度系統權限、進程管控類場景。

其次，存在命令沖突問題。dir/more/whoami等和 Windows 原生命令重名，為了系統穩定直接放棄兼容。同時受PATH 順序、PowerShell別名影響，同一條命令在不同終端表現可能不一樣，復雜環境需要手動排錯。

最后，運行邏輯仍然存在差異。換行符、文件路徑、權限邏輯、特殊字符處理，Windows和 Linux天生不同。復雜Shell腳本、依賴底層POSIX特性的程序，依然大概率跑不通。

因此，在Windows下運行Linux專屬服務、編譯環境、完整容器、依賴系統調用的軟件，依舊必須用WSL。