WSL 最容易被误解成“Windows 里的虚拟机”。它确实像一台小 Linux，但它和传统虚拟机的边界更薄：文件、网络、进程工具链、编辑器、终端体验都可以和 Windows 宿主机互相借力。理解这层关系以后，WSL 就不再只是一个能敲 apt 的窗口，而是 Windows 上最顺手的开发工作台之一。
这篇文章不追求把所有命令列完，而是把 WSL 和宿主机之间的关系讲清楚：什么时候该把项目放进 WSL，什么时候该留在 Windows；怎么配置才好用；哪些项目真的适合 WSL。
WSL 和宿主机到底是什么关系
可以把 Windows 看成桌面和硬件资源的总管，把 WSL 看成嵌在旁边的一套 Linux 用户态环境。你平时打开 VS Code、浏览器、文件管理器、截图工具、网盘客户端，这些仍然属于 Windows；你在 WSL 里跑 bash、git、ssh、python、node、docker、make，它们更接近 Linux 服务器上的使用方式。
两边不是完全隔离的。WSL 可以访问 Windows 盘符，例如 /mnt/c/Users/...；Windows 也可以通过 \\wsl$ 或 \\wsl.localhost 访问 WSL 文件系统。WSL 进程可以调用 Windows 程序，Windows 终端和编辑器也可以把 shell 直接开进 WSL。
真正要记住的是：WSL 适合承载开发运行环境，Windows 适合承载桌面交互和文件分发。把这两件事混在一起并不是不行，但项目越大，边界越清楚，体验越稳定。
文件应该放在哪里
最重要的一条经验是：Linux 项目尽量放在 WSL 自己的文件系统里，比如 ~/projects/my-app，不要长期放在 /mnt/c/... 下面开发。
原因很现实。大量小文件读写、依赖安装、Git 状态扫描、构建缓存，这些在 Linux 文件系统里通常更快，也更符合工具预期。Node.js 的 node_modules、Python 虚拟环境、Rust 的 target、Go 的 module cache，放在 WSL 里会少很多奇怪的性能和权限问题。
Windows 盘符更适合放文档、下载文件、需要被桌面软件直接处理的资料。如果一个项目主要由 Windows 软件编辑，比如 Office 文档、Photoshop 素材、剪辑工程，那它就没必要硬塞进 WSL。
一个好用的分工可以是：
|
|
让 WSL 变好用的基础配置
第一步是选一个稳定发行版。大多数开发场景用 Ubuntu LTS 就够了，资料多，包也全。安装后先更新基础包：
|
|
然后把日常工具补齐：
|
|
第二步是把终端体验调顺。Windows Terminal 配合 WSL 已经很好用，可以把默认配置设成你的 WSL 发行版，再按喜好配置字体、配色和启动目录。shell 不一定非要上复杂框架，先保证提示符清楚、历史记录好用、复制粘贴自然，效率就会明显提升。
第三步是把 VS Code 接上 WSL。安装 Remote - WSL 扩展后，在 WSL 项目目录里执行：
|
|
这样 VS Code 的界面跑在 Windows，扩展、终端、语言服务和调试进程跑在 WSL。你看见的是 Windows 应用，实际用的是 Linux 开发环境，这正是 WSL 最舒服的地方。
Git、SSH 和凭据怎么放
如果项目主要在 WSL 里开发，Git 和 SSH 也建议在 WSL 里配置一套。这样远程仓库认证、提交签名、脚本调用都不需要跨系统绕来绕去。
常见配置包括：
|
|
私钥放在 WSL 的 ~/.ssh 里，权限也按 Linux 习惯处理：
|
|
如果你已经在 Windows 里配置过 Git 凭据，也可以继续用，但不要让同一个项目一会儿由 Windows Git 操作，一会儿由 WSL Git 操作。换行符、权限位、文件监听和 hooks 都可能因此变得混乱。一个仓库最好固定一个主操作环境。
网络关系怎么理解
WSL2 背后有虚拟化网络，所以它和 Windows 不是完全同一个网络命名空间。大多数日常开发里，你在 WSL 里启动服务，Windows 浏览器可以直接访问 localhost:端口。反过来，WSL 访问 Windows 侧服务时，常常需要使用宿主机地址。
实际排查时可以按这个顺序想：
|
|
如果只是本机开发，不要急着改一堆网络设置。先确认服务到底跑在哪边，监听的是 127.0.0.1 还是 0.0.0.0，再决定要不要开防火墙规则。
Docker 和 WSL 的关系
Docker Desktop 在 Windows 上很好用，其中一个关键原因就是它可以把 Linux 容器运行环境接到 WSL2。对开发者来说，最自然的姿势是：代码放在 WSL，Docker Desktop 开启 WSL integration，然后在 WSL 里执行 docker compose up。
这种方式适合 Web 后端、数据库、本地中间件、CI 环境复刻。比如一个项目需要 PostgreSQL、Redis、MinIO、Nginx，再加一个 Node 或 Python 服务，用 WSL + Docker Compose 往往比纯 Windows 环境省心。
需要注意的是，容器挂载路径也尽量来自 WSL 文件系统。把容器大量读写挂到 /mnt/c/...，性能和权限问题会更容易出现。
什么项目适合使用 WSL
最适合 WSL 的项目通常有几个共同点：生产环境偏 Linux，依赖安装偏命令行，构建链路对文件系统和 shell 行为比较敏感。
典型例子包括：
- Web 后端：Node.js、Python、Go、Rust、PHP、Ruby 项目。
- DevOps 工具：Ansible、Terraform、kubectl、Helm、CI 脚本、本地部署脚本。
- Linux 服务复刻：Nginx、Redis、PostgreSQL、MySQL、队列和对象存储组合。
- 开源项目编译：需要
make、gcc、cmake、shell 脚本的仓库。 - 静态站点和博客：Hugo、Astro、Next.js、Vite 这类命令行驱动的项目。
如果项目最终要部署到 Linux 服务器，WSL 可以减少“我本机能跑，服务器不行”的落差。你在本机越接近生产环境，问题暴露得越早。
什么项目不必强行使用 WSL
WSL 不是万能默认项。纯 Windows 桌面开发、.NET Windows 桌面应用、游戏引擎工程、Office 自动化、重度依赖 Windows 驱动或 GUI 软件的项目，留在 Windows 原生环境通常更自然。
还有一种情况是团队规范已经明确要求 Windows 工具链，比如固定 Visual Studio、固定 MSVC、固定 Windows SDK。此时 WSL 可以作为辅助命令行工具，但不应该反客为主。
判断标准很简单：如果项目的核心运行环境是 Linux，优先 WSL；如果核心交互和构建都依赖 Windows，优先 Windows。
日常使用里的几个坑
第一，不要在同一个仓库里混用两套包管理环境。比如在 Windows 里 npm install 一次，又在 WSL 里 npm install 一次，依赖目录可能变得很难排查。
第二，注意换行符。建议在仓库里配置 .gitattributes，让文本文件的换行规则固定下来，而不是靠每个人的 Git 默认配置猜。
第三，别把 WSL 当成临时垃圾桶。开发时间长了，~/projects、Docker volume、语言包缓存都会膨胀。定期清理不用的容器、镜像和构建缓存，比等磁盘爆掉再救舒服得多。
第四，明确备份边界。Windows 侧同步盘未必会备份 WSL 内部文件系统。重要仓库靠 Git，重要配置可以单独导出，别默认“都在电脑里所以都安全”。
我的推荐工作方式
我更推荐把 WSL 当成“Linux 项目的主工作间”，而不是 Windows 的小插件。
一个顺手的日常流程是：
|
|
这套流程的好处是边界清晰：编辑体验是 Windows 的，开发环境是 Linux 的，项目文件也在 Linux 这边。你既不用放弃 Windows 桌面生态，也不用为了 Linux 工具链折腾一整台虚拟机。
总结
WSL 好不好用，关键不在于装了多少终端插件，而在于有没有摆正它和宿主机的关系。Windows 负责桌面、浏览器、图形软件和日常管理；WSL 负责代码、依赖、容器、脚本和接近生产环境的 Linux 工具链。
当项目面向 Linux 部署，或者依赖大量命令行工具时，WSL 会让 Windows 变成一台非常舒服的开发机。当项目天然属于 Windows 桌面生态时，直接用 Windows 反而更干净。
把边界分清楚，WSL 就会从“偶尔打开的黑框”变成真正稳定的开发工作台。