适用于 Linux 的 Windows 子系统（英语：Windows Subsystem for Linux，简称WSL）是一个为在Windows 10和Windows Server 2019上能够原生运行Linux二进制可执行文件（ELF格式）的兼容层。
WSL提供了一个由微软开发的Linux兼容的内核接口（不包含Linux内核代码），然后可以在其上运行GNU用户空间，例如Ubuntu，openSUSE，SUSE Linux Enterprise Server，Debian和Kali Linux。这样的用户空间可能包含Bash shell和命令语言，使用本机GNU/Linux命令行工具（sed，awk等），编程语言解释器（Ruby，Python等），甚至是图形应用程序（使用主机端的X窗口系统）。
在周年更新中引入时，只有Ubuntu镜像可用。秋季创意者更新将Linux发行版的安装过程移至Microsoft商店，并引入了Fedora和SUSE镜像。
WSL仅在版本1607之后的64位版本的Windows 10中可用。它也可在Windows Server 2019中使用。
微软首次尝试在Windows上实现类似Unix的兼容性，首先是微软POSIX子系统，由Windows Services for UNIX通过MKS/Interix取代，后者最终因Windows 8.1的发布而被弃用。Windows Subsystem for Linux背后的技术起源于未发布的Astoria项目，它使一些Android应用程序能够在Windows 10 移动版上运行。它首先在Windows 10 Insider Preview build 14316中提供。
虽然微软以前的项目和第三方Cygwin专注于基于POSIX标准创建自己独特的类Unix环境，但WSL的目标是原生Linux兼容性。WSL不是将非原生功能包装到Win32系统调用中，而是利用NT内核执行程序将Linux程序作为特殊的、隔离的最小进程（称为）作为专用系统连接到内核模式。调用和异常处理程序不同于vanilla NT进程。
微软将WSL视为“主要面向开发人员的工具 — 尤其是Web开发人员以及在开源项目上工作或使用开源项目的人员”。WSL使用的资源少于完全虚拟化的机器，这是在Windows环境中运行Linux软件的最直接方式，同时还允许用户在同一组文件上使用Windows应用程序和Linux工具。
2020年9月，WSL 2开始向Windows 10 Version 1903/1909和Windows 10 May 2020（20H1/Version 2004）的用户推送。WSL 2支持GUI应用。
LXSS Manager Service是负责与子系统交互的服务（通过lxss.sys和lxcore.sys），以及Bash.exe（不要与Linux发行版提供的Shell混淆）的方式启动Linux进程，以及在执行期间处理Linux系统调用和二进制锁。
特定用户调用的所有Linux进程都进入“Linux实例”（通常，第一个调用的进程是init）。关闭所有应用程序后，将关闭实例。
由于没有硬件仿真/虚拟化（与coLinux等其他项目不同），WSL直接使用主机文件系统（通过VolFS和DrvFS）和硬件的某些部分，例如网络（Web服务器，用于例如，可以通过主机上配置的相同接口和IP地址进行访问，并且对使用需要管理权限的端口或已经被其他应用程序占用的端口共享相同的限制），这保证了互操作性。
即使从shell运行sudo，某些位置（例如系统文件夹）和配置的访问/修改也受到限制。必须启动具有提升权限的实例才能获得“真正的sudo”并允许此类访问。
此子系统无法运行所有Linux软件（如32位二进制文件）或需要在WSL中未实现的特定Linux内核服务的软件。由于WSL中没有“真正的”Linux内核，因此无法运行内核模块（如设备驱动程序）。
可以通过在Windows（主机）环境（例如VcXsrv或Xming）中安装X窗口系统来运行一些图形（GUI）应用程序（例如Mozilla Firefox），尽管并非没有警告，例如缺乏音频支持或硬件加速（导致图形性能不佳）。目前还没有实施对OpenCL和CUDA的支持，尽管计划在将来的版本中使用。
也就是说，微软明确指出WSL面向应用程序的开发者，而不是面向桌面环境或生产服务器，建议使用虚拟机（Hyper-V或Kubernetes）和Azure来实现这些目的。
在性能测试中，Windows Subsystem for Linux通常接近原生Linux，如Ubuntu，Debian，Intel Clear Linux或其他Linux发行版。I/O在某些测试中是WSL的瓶颈。
运行于WSL中的Firefox
运行于WSL中的Synaptic