JetBrains IDE 的 WSL 支持演进：Native 模式成为推荐方案
译注：本文翻译自 JetBrains 官方博客 2026 年 9 月 9 日发布的文章 The Evolution of WSL Support in JetBrains IDEs，作者 Kristina Pchelintseva。原文链接见文末。
JetBrains IDE 与 WSL 的协作已有多年历史，期间在不同产品中演化出多种使用方式。由于入口不同，IDE 可能依赖不同的底层架构，最终带来截然不同的体验。
从 2026.2 版本开始，JetBrains 统一了推荐入口。在 IntelliJ IDEA、WebStorm 和 PhpStorm 中，打开位于 WSL 中的项目会让 IDE 以所谓的 Native 模式运行：IDE 本身仍是 Windows 应用，而 WSL 内部的一个小型 agent 代为处理文件与进程操作。
在 IDE 中支持 WSL 意味着什么
理想状态下，IDE 运行在 Windows 上，却能无缝操作 WSL 内的项目——终端、运行/调试配置、性能分析等功能都应对 Linux 环境中的项目生效，且延迟要尽可能低，让编码体验如同项目文件与 IDE 处于同一个操作系统环境中。
JetBrains 先后尝试了四种方案，最终收敛到 Native 模式。
早期方案一：9P 文件系统与 GeneralCommandLine
最早的实现通过 9P 传输协议让 Windows 侧进程访问 WSL 内的文件。项目相关的文件 I/O（扫描、索引、归档访问等）都经由 9P 文件系统层路由到 Linux 虚拟机。进程执行方面，则由 IDE 内部的 GeneralCommandLine 类负责在 WSL 环境中规范化命令执行。
这一架构存在明显代价：
- 符号链接处理受限：9P 无法通过
\\wsl$正确向 Windows 暴露 Linux 符号链接，导致 IDE 可能检测到条目却无法解析或索引链接的目录树。这会影响 pnpm workspaces、Python 虚拟环境、PHP Composer path repositories 等依赖符号链接的场景。 - Microsoft Defender 扫描：通过 9P 的实时扫描可能让 WSL 文件读取延长数十秒。
- 延迟与吞吐下降：9P 文件系统访问增加延迟，吞吐量在涉及大量小文件的工作流中显著劣化。索引等核心操作正是这种模式，会产生大量跨越 Windows/WSL 边界的独立请求。
GeneralCommandLine 一侧同样棘手，开发者必须在整个代码库中考虑 WSL 特有的执行语义，维护负担沉重，方案越来越难以扩展。
早期方案二：WSLg 中运行 IDE
另一种思路是让 IDE 本身运行在 WSL 内，靠近项目，通过 WSLg 将 Linux GUI 应用的画面集成到 Windows 桌面。JetBrains 并不推荐这一方案：
- 从产品角度看，如果 IDE 显示在 Windows 上，它更应表现为 Windows 原生应用，而非投影到 Windows 桌面的 Linux GUI 应用。
- 在 WSLg 设置中，IDE 可能走原生 Wayland 路径，JetBrains Runtime 使用 WLToolkit 对接 WSLg 的 Wayland compositor，该路径在渲染、弹窗、窗口管理、输入法和桌面集成方面存在已知限制。
- 从未围绕此方案构建一等产品体验，也没有专门的开箱即用安装或引导流程，它始终是一种临时变通而非受支持的 IDE 工作流。
早期方案三：Remote Development
Remote Development 从另一个角度解决文件访问与进程执行问题：把 IDE 后端移入 WSL，Windows 上只保留客户端。两端通过 JetBrains RD 协议通信，该协议以结构化的双向流同步 IDE 模型与事件，索引、分析、构建、调试、VCS 等重活都在后端完成；客户端负责渲染窗口与编辑器、处理输入、镜像状态并回传编辑与调试操作，同时加载 UI 级插件。
这一架构更直接地解决了集成问题，但代价同样明显：IDE 后端本身是重量级组件，在 WSL 内安装需要约 2 GB 额外磁盘空间和下载安装时间；拆分架构带来固有性能损耗，UI 事件状态与用户输入需在客户端与后端间持续传输；代码必须拆分为客户端与服务端两部分，未拆分的模块可能导致高动态 UI 卡顿，相关工程投入成为持续成本。
Native 模式与 IJent agent
当前设计已集成到大多数 JetBrains IDE 中，它不依赖 9P、GeneralCommandLine 或其他次等通信机制，而是通过一个名为 IJent 的小型 agent 访问 Linux 文件系统、进程及其他环境资源。由于专为 IDE 场景设计，其行为、协议与能力都可按需定制。
IDE 与 IJent 构成客户端–服务端对，但服务端组件远比 Remote Development 轻薄，同时更通用。将 IJent 安装进 WSL 只是多种可能配置之一，同一模型也适用于 Docker 和 Dev Containers。
技术选型上的考量包括：
- Rust 实现：保持可执行文件精简，避免在容器或 WSL 内引入 Java/Kotlin 运行时依赖。
- 传输层：Stdio 提供可移植、对防火墙友好的传输方式；WSL 上的 Hyper-V sockets 提供更快的路径，对大量文件系统传输尤为有利。
- 正确的文件系统语义：IJent 在目标环境内代表 IDE 执行文件系统操作，路径解析（包括符号链接）遵循正确的 Linux 语义，而非经由 9P 中介。第三方插件的文件操作同样路由至 IJent，因而一并受益。
EelApi：面向任意环境的统一接口
要让 IDE 充分受益于 IJent，IDE 侧也需改动，这就是 EelApi。它旨在为所有编写 IDE 相关代码的人——插件作者与平台贡献者——抽象掉本地与远程环境的差异。有了 EelApi，IDE 运行于何种底层环境不再重要，代码中无需显式处理这些差异。IJent 实现了 EelApi 接口，提供 EelApi 向 IDE 与插件暴露的实际功能。
实际效果
目前打开 WSL 项目有两种方式：
- 直接打开项目，在 IntelliJ IDEA、WebStorm 和 PhpStorm 中即进入 Native 模式，更多 IDE 正在采纳 IJent 与 EelApi 架构。
- 欢迎界面上的 Remote Development 入口仍然可用，但已不再是打开 WSL 项目的推荐方式。
JetBrains 对 9P 模式与 Native 模式进行了性能对比，结果如下：
| 冷启动基准 | 9P | IJent | 变化 |
|---|---|---|---|
| 可开始工作 | 18.5 s | 11.5 s | 减少 38% |
| 扫描项目树 | 8.1 s | 3.7 s | 减少 54% |
| 索引文件 | 10.8 s | 8.4 s | 减少 22% |
| 读取文件内容 | 12.2 s | 5.7 s | 减少 53% |
测试场景为首次冷启动 spring-framework，含 23 个子项目、8,191 个源文件；源文件很少的小项目未观察到可测量差异。测试环境为 Windows 11 + WSL 2、Ubuntu 24.04、IntelliJ IDEA Ultimate 263.SNAPSHOT，取五次运行的中位数。
除性能外，这一架构还将 WSL 中的开发纳入非本地环境开发的整体框架，使 Docker 与 Dev Containers 可以采用同一底层模型——同一个 IJent agent 已经支撑着 JetBrains 在 Docker 和 Dev Containers 方面的工作。