最近有个朋友跟我倒苦水：他手头的小项目必须在Linux环境下编译，可主力机是Windows，每次都得先折腾半天环境。这个场景其实太常见了——很多开源工具链只发布了Linux版本，日常脚本依赖Linux的命令行习惯，或者部署目标是Linux服务器，本地又不想丢掉Windows的办公生态。这篇文章就围绕一件非常具体的事展开：如何在Windows上运行Linux程序，并附上可以照着敲的示例代码。
我会先从需求场景讲起，帮你判断该选哪条路线，然后把重点放在当前体验最顺、日常使用最频繁的WSL2上，从环境搭建、示例代码到文件互操作和性能调优，一步步说清楚。文中所有操作和代码我都按“我能直接复现”的标准来写，不绕弯子。适合两类人看：一类是刚接触跨平台开发、想在Windows里跑Linux工具的新手；另一类是已经在用WSL，但想解决文件交换、内存占用、端口互通等具体问题的开发者。
1. 为什么需要“在Windows上运行Linux程序”：先看清需求再选方案
1.1 高频典型场景：你不是少数人
我见过的大多数需求，可以归成四类。第一类是工具链依赖，比如某个编译器、模拟器或测试框架只提供Linux版，Windows下要么没有，要么处于半放弃维护的状态。第二类是环境一致性，本地开发环境和服务器不一致，代码在Windows上好好的，部署到Linux就崩，你需要在本地先跑一遍Linux环境。第三类是开源程序复现，很多论文或开源项目给的示例代码、构建脚本就是面向Linux的，在Windows上按步骤走总差那么几步。第四类是运维习惯，有些人写自动化脚本就爱用bash，PowerShell虽然强大，但语法习惯差异不小，直接跑Linux脚本更省事。
这些场景的共同点是你并不想彻底抛弃Windows，只是想借用Linux的能力。想清楚这一点，接下来的方案选择才有方向。
1.2 程序类型直接决定方案取舍
开始之前，建议你先问自己：需要运行的Linux程序，到底是命令行工具，还是服务型程序，还是有图形界面，或者需要直接操作内核？这个问题非常关键，因为它直接决定了用什么方案。
我整理了一张粗略的对应表：
| 程序形态 | 推荐方案 | 理由 |
|---|---|---|
| 命令行工具、构建脚本、编译器 | WSL2 | 起步快、资源占用小、和Windows集成好 |
| Web服务、数据库、后端进程 | 容器引擎 | 隔离干净、环境可复用，现代方案一般也要依赖WSL2做后端 |
| 图形界面程序 | 虚拟机或新版WSL的图形支持 | 图形渲染需要完整显示栈，虚拟机最稳 |
| 内核模块、自定义驱动 | 虚拟机 | 需要完整Linux内核和设备访问权限 |
这个表格是一个参考，不是绝对标准。如果你的需求是“偶尔跑一下Linux命令”，那WSL2基本就是最优解；如果需求是“完整复现一套Linux服务器环境”，那容器或虚拟机更合适。下面我展开对比四条主流路线。
2. 四条主流路线对比：虚拟机、容器、WSL2与远程开发
2.1 虚拟机：最完整的Linux，但开销也最大
虚拟机的思路是在Windows上虚拟出一台完整电脑，在里面安装一个完整的Linux系统。它的好处是隔离性最强，Linux内核、设备驱动、桌面环境统统都有，你想做什么都行，几乎和真机没区别。
代价也很明显：资源开销大、启动慢、平时要维护一个完整的操作系统。一台8GB内存的电脑，虚拟机里分上4GB之后，Windows这边就会明显紧张。虚拟机的磁盘文件也会占掉几十GB空间，日常命令行工作用它，有点杀鸡用牛刀的感觉。适合的场景是：你需要Linux图形桌面，或者需要编译/加载内核模块，又或者需要一个完全独立的实验环境。
2.2 容器：轻量但共享内核，服务型程序的好选择
容器和虚拟机不一样，它不虚拟整套硬件，而是共享宿主机内核，只做进程和文件系统层面的隔离。因为不需要跑完整操作系统，容器启动速度可以做到秒级，镜像复用之后部署非常方便。
在Windows上跑Linux容器，现代方案基本都依赖WSL2作为后端，也就是说你先得把WSL2环境搭好。容器的典型使用场景是跑服务型程序，比如一个Python后端、一个数据库、一套Web应用。你把依赖、配置、启动命令打包进镜像，换一台机器也能得到一致的运行结果。不过容器不适合需要直接操作内核、加载内核模块的程序，它的隔离机制决定了那些操作会被拦下来。
2.3 WSL2：命令行场景的综合最优解
WSL2（Windows Subsystem for Linux 2）是当前Windows上运行Linux程序最实用的一条路线。它的设计思路是把一个精简的Linux内核跑在Windows自带的轻量虚拟化平台上，同时保留和Windows高度互通的体验。
相比虚拟机，WSL2启动只需要一两秒钟，内存可以动态回收，不会一上来就吃掉固定的大块内存。相比传统翻译层方案，WSL2因为用了真正的Linux内核，兼容性更好，绝大多数Linux二进制程序都能直接跑。再加上它和Windows文件系统、命令行的深度集成，日常写代码、跑脚本、做测试都非常顺手。这也是后文示例代码选择WSL2作为主线的原因。
2.4 远程开发与交叉编译：不一定要在本地跑Linux
如果你的目标只是“在Windows上编写和调试Linux程序”，其实还有一个轻量思路：代码放在Windows本地，用一个支持远程开发的编辑器连到一台Linux机器上，在远程执行所有编译和运行命令。本地只负责写代码和看输出，这种感觉也近似于“在Windows上运行Linux程序”。这种方式适合你已经有一台可用的Linux服务器或开发机。
另一种情况是交叉编译，直接在Windows上编译出Linux可执行文件。理论上可行，但Linux程序依赖动态库、链接器、系统调用，交叉编译工具链很容易在依赖上卡脖子。除非是写完全静态的简单程序，否则日常使用我还是更推荐WSL2或远程开发，省心太多。
3. 搭建WSL2环境：从打开终端到第一个能跑的程序
3.1 前置条件与版本确认
安装WSL2之前，先确认三件事。第一，Windows版本够不够新，建议在Windows 10的2004版本以上，或者直接用Windows 11，这样能享受到最新的WSL改进。第二，主板BIOS里要开启虚拟化支持，大部分现代电脑默认开启，如果你是老机器或者自定义装机，需要进BIOS确认一下。第三，终端要以管理员权限打开。
确认方式很简单，在PowerShell里运行：
wsl --status如果提示找不到命令，说明你的Windows版本比较旧；如果能看到版本状态，说明已经具备基础条件。
3.2 一条命令完成安装
在较新的Windows版本上，安装WSL2已经收敛为一条命令，在管理员终端里执行：
wsl --install这条命令会自动完成几件事：启用运行WSL所需的Windows组件、下载并部署一个默认的Linux发行版、把默认版本设置为WSL2。执行完之后按提示重启电脑，重启后系统会进入发行版的初始化流程，让你创建一个Linux用户名和密码，之后就进入了Linux环境。
如果你想自己指定发行版，可以先查看在线可用的列表：
wsl --list --online然后安装指定的发行版：
wsl --install -d <发行版名称>安装完成后，随时可以打开新的终端窗口，输入wsl直接进入默认的Linux环境。
3.3 首次配置与基础工具安装
进入Linux环境后，我建议先做三件事，算是环境初始化的“三件套”。第一，确认内核和系统信息：
uname -a看到一串包含WSL2字样的Linux内核信息，就说明环境正常。第二，更新软件源和基础软件包，主流的发行版一般用：
sudo apt update && sudo apt upgrade -y这个过程会把软件索引刷新，并升级已安装的包。第三，安装编译和运行示例代码要用到的工具：
sudo apt install -y build-essential python3 python3-pipbuild-essential带了gcc、g++、make这些编译基础工具，Python环境也一并装上。
3.4 WSL1与WSL2：两代架构的区别
安装命令默认会使用WSL2架构，但有些老环境可能还是WSL1。WSL1没有虚拟机的内核，而是通过翻译层把Linux系统调用转成Windows调用，优点是启动极快、跨文件系统访问原生一些；缺点是有些程序对系统调用支持不完整，会有兼容性问题。WSL2则用轻量虚拟机承载真正的Linux内核，兼容性大幅提升，是目前的主流。
如果你的发行版还在WSL1，想切换到WSL2，可以执行：
wsl --set-version <发行版名称> 2一般情况我都会建议用WSL2，除非你有特别依赖WSL1文件系统语义的边缘场景。
4. 附示例代码：三种语言与一个网络服务的完整演示
4.1 C语言程序：编译工具链正确性的试金石
进入WSL后，随便建一个目录，写一个C程序。用nano、vim，或者直接在Windows侧用编辑器写完放到WSL里都行。
创建hello.c：
#include <stdio.h> int main(void) { printf("Hello from Linux, running on Windows!\n"); return 0; }用gcc编译：
gcc hello.c -o hello ./hello输出会是：
Hello from Linux, running on Windows!为什么这里要写./hello而不是直接写hello？因为Linux默认不把当前目录加入可执行文件的搜索路径，直接输入hello会让shell去PATH目录里找，通常找不到。养成用./的习惯，后续执行脚本和程序都会少很多困惑。
4.2 Python脚本：Windows兼容性问题的一个典型
Python本身是跨平台的，但很多科学计算、数据处理相关的库在Windows上的二进制分发并不完整，或者行为有细微差异。在WSL里跑Linux版Python，会更接近生产环境。
创建一个fib.py：
def fib(n): a, b = 0, 1 for _ in range(n): a, b = b, a + b return a for i in range(10): print(f"fib({i}) = {fib(i)}")执行：
python3 fib.py输出Fibonacci数列的前十项。这个例子很小，但它验证了Python解释器、脚本执行权限、输出编码等基础链路都没问题。后续你安装第三方库，比如用pip install安装某个只提供Linux轮子的包，在WSL里会顺利很多。
4.3 Shell脚本：处理批量重命名和文本操作
Shell脚本是Linux环境下的高频需求。下面这个脚本把当前目录下所有.txt文件重命名为.bak后缀：
#!/bin/bash for file in *.txt; do [ -e "$file" ] || continue mv "$file" "${file%.txt}.bak" done先把内容保存为rename.sh，然后赋予执行权限：
chmod +x rename.sh ./rename.sh其中chmod +x是给脚本添加可执行权限。如果你是从Windows侧拷贝这个文件到WSL里，可能会遇到换行符问题，导致脚本报\r: command not found。这个问题我在下一章详细讲。
4.4 网络服务：在Windows浏览器中访问WSL里的程序
WSL2有一个很实用的特性：WSL里监听的端口，Windows通常可以直接通过localhost访问。我经常用这个方式快速启动一个本地服务来验证代码。
在WSL里启动一个简单的HTTP服务：
cd /home/<你的用户名> python3 -m http.server 8000然后打开Windows浏览器，访问：
http://localhost:8000你就能看到那个目录的文件列表。这说明Linux程序在WSL里跑起来之后，网络链路和Windows是通的。如果访问不到，一般是WSL版本较旧或者端口转发被关闭，可以先用ip addr查看WSL的IP，然后用http://<WSL-IP>:8000尝试，不过新版默认情况下localhost转发已经很好用了。
5. 文件系统互操作与文本编码：最常见的小麻烦
5.1 两套文件系统，两条访问路径
WSL2里其实存在两套文件系统。一套是Linux自己的ext4文件系统，固定在WSL的虚拟磁盘里，性能好，是存放代码和工作文件的首选位置。另一套是Windows文件系统的挂载点，所有Windows盘符都在Linux环境下以/mnt/<盘符>的形式出现，比如C盘就是/mnt/c。
在Linux里访问Windows文件：
cd /mnt/c/Users/<你的用户名>/Desktop ls -l在Windows里访问WSL文件，可以在资源管理器的地址栏输入：
\\wsl$或者：
\\wsl$\<发行版名称>\home\<你的用户名>这样Windows侧的程序也能直接读写WSL里的文件，两边互通很方便。
5.2 使用wslpath转换路径
路径格式不同常常让人头晕，好在WSL提供了一个专门的转换命令wslpath。在WSL里执行：
wslpath 'C:\Users\<你的用户名>\Desktop\file.txt'会输出对应的Linux路径：
/mnt/c/Users/<你的用户名>/Desktop/file.txt反向转换用-w参数：
wslpath -w '/home/<你的用户名>/file.txt'这个命令在写脚本时特别有用，可以把Windows路径作为参数传给Linux程序。
5.3 CRLF、LF与可执行权限
Windows上的文本文件默认用回车换行（CRLF），Linux则只用换行（LF）。当你把一个Windows编辑器保存的脚本拷贝进WSL直接执行，经常会出现一个诡异报错：bash: script.sh: /bin/bash^M: bad interpreter。
处理办法很简单，把回车符去掉：
sed -i 's/\r$//' script.sh执行完再试，脚本就能正常运行了。如果这个项目用了Git，建议在Windows侧配置一下core.autocrlf，让Git在检出时自动转换换行符，能从源头减少这类问题。
另外，从Windows复制到WSL里的文件，默认可能没有Linux可执行权限，所以chmod +x script.sh这步不要省略。中文内容方面，大部分现代发行版默认UTF-8编码，和Windows下的新编辑器一致；如果你要处理旧版GBK编码的文件，可以用iconv先做转码。
6. 踩坑记录与性能调优：让程序稳定运行，磁盘和内存不失控
6.1 端口互通的两个小坑
虽然WSL2的localhost转发很方便，但偶尔也会遇到失效的情况。常见原因有两个：一是WSL版本太旧，内核没有启用对应的转发机制；二是服务启动时监听在某个特定IP上，而不是0.0.0.0。比如Python的http.server默认监听所有接口，一般没问题；但某些服务默认只监听127.0.0.1，Windows侧访问时可能就切换不到。
排查思路是先在WSL里确认监听地址：
ss -tlnp | grep 8000如果看到的是127.0.0.1:8000，就要到服务的配置里改成0.0.0.0。Windows防火墙第一次拦截WSL进程的入站连接时，会弹窗询问，记得允许，否则外部程序访问WSL端口也会不通。
6.2 用.wslconfig限制内存与CPU
WSL2默认的内存管理是动态增长，但它有个特点：最多可能占用Windows一半的物理内存。如果电脑内存不大，跑几个Linux程序之后Windows会明显变卡。这里可以用.wslconfig文件做限制。
在Windows侧创建或编辑C:\Users\<你的用户名>\.wslconfig：
[wsl2] memory=4GB processors=4 swap=2GB保存之后，在PowerShell里执行wsl --shutdown，再重新打开WSL，配置就会生效。注意这个文件是Windows侧的，不是Linux侧。很多人在Linux里到处找这个文件找不到，就是这个原因。
6.3 虚拟磁盘只增不减
WSL2的Linux文件系统存放在一个虚拟磁盘文件里，这个文件会随着使用不断增大，但删除文件之后它不一定会自动还给宿主机，导致Windows侧看到磁盘占用一直涨。解决办法是压缩虚拟磁盘。
流程大致是：先备份重要数据，然后在PowerShell里执行wsl --shutdown，再用Windows自带的磁盘管理工具找到WSL的虚拟磁盘文件进行压缩。具体工具名称不同版本略有差异，操作前务必确认备份完整。这属于低频维护操作，我一般两三个月做一次，做完能让磁盘占用明显回落。
6.4 启用systemd以支持后台服务
新版WSL2已经支持systemd，这对跑后台服务很重要。默认情况下有些发行版没有开启systemd，你执行systemctl start xxx会报错说没有连上systemd。
开启方式很简单，编辑WSL里的/etc/wsl.conf：
[boot] systemd=true保存后回到Windows侧执行wsl --shutdown，再重新进入WSL，执行systemctl status确认systemd已经运行。之后就能用systemctl管理Linux服务了，比如开机自启某些程序，或者运行数据库服务。
6.5 双向调用：Windows命令与Linux命令互相使用
WSL一个很实用的点是双向互操作。在Windows的PowerShell或CMD里，可以直接调用Linux命令：
wsl bash -c "ls -l /etc/passwd"在WSL里，也可以调用Windows程序。比如想用Windows记事本打开WSL里的一个文本文件：
/mnt/c/Windows/System32/notepad.exe log.txt这会直接唤起Windows记事本，并在里面打开Linux侧的文件。对于那些“Windows有现成工具、Linux侧没有”的场景，这个能力非常方便。建议你把WSL的路径挂在终端里，随时双向跳转。
结尾：我的日常使用习惯
最后分享一点个人经验。我现在的习惯是，所有和开发相关的文件一律放在WSL的Linux文件系统里，Windows侧编辑器通过\\wsl$路径去访问；只有在需要把产物交给Windows工具链时，才复制到/mnt/c下面。这样做的好处是避开了跨文件系统IO性能损耗，Git关联文件也不会被奇怪的换行符问题反复纠缠。
每次新建一个WSL环境，我总会先做三件事：更新软件索引、安装build-essential、把所有脚本文件统一转成LF换行。这套流程走下来，基本没有遇到过环境导致的诡异问题。如果你打算长期在Windows上运行Linux程序，我建议你也把这套流程固化下来，省下的时间远比研究各种临时方案多得多。
