里程碑：Windows加入原生Linux命令！是否可以抛弃WSL了？

以往在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。