从2026.2版本开始，在IntelliJ IDEA、WebStorm和PhpStorm中打开位于Windows Subsystem for Linux（WSL）内的项目时，将进入JetBrains所称的Native模式。在这种模式下，IDE仍是运行于Windows上的应用程序，而WSL内部的一个小型代理负责代表它执行文件操作和进程操作。公司表示，这是目前推荐的入口；Remote Development选项仍可从欢迎屏幕使用，但已不再是打开WSL项目的首选方式。
这并不只是用户界面上的名称变化。开发环境要支持位于WSL中的Linux项目，就必须访问文件、使用正确的路径运行工具、管理环境变量，并执行构建、调试和性能分析操作，同时将延迟保持在足够低的水平，使体验看起来足够自然。JetBrains解释说，以前的方法会根据入口不同而使用不同的架构，导致不同产品和场景之间的性能与行为存在差异。
为什么9P路径已不够用？
在较早的方法中，Windows上的JetBrains应用通过9P文件系统协议访问WSL文件，而GeneralCommandLine类负责规范化Linux环境中的运行命令。这使IDE能够针对WSL项目运行，但也使大量读取和索引操作需要跨越Windows与承载WSL的虚拟机之间的边界。
据JetBrains介绍，这带来了三个主要问题。首先，9P无法通过\\wsl$路径正确呈现Linux符号链接，这可能导致IDE无法解析或索引某些目录树。使用符号链接的环境会受到影响，例如pnpm工作区、Python虚拟环境以及依赖路径的Composer仓库。其次，Microsoft Defender在访问时进行扫描，可能使读取WSL文件的时间延长几十秒。第三，对于涉及大量小文件的操作（例如索引），该协议会增加明显的额外延迟。
此外，命令执行层还迫使平台开发者在代码库的不同部分处理WSL特有的语义。JetBrains认为，这使该方法更难扩展和维护，无法成为非本地工作环境的统一基础。
Remote Development带来了什么？
Remote Development从相反方向解决了这一问题：完整的IDE后端迁移到WSL，而Windows上保留一个负责显示界面和接收用户输入的客户端。双方通过JetBrains RD协议通信，该协议双向传输事件模型、编辑器状态和项目状态。索引、分析、构建、调试和版本控制操作等重量级任务则在靠近文件的WSL内部执行。
这种设计消除了对9P直接访问文件的依赖，但也增加了其他成本。JetBrains表示，后端需要额外约2GB磁盘空间，同时还需要在WSL内部下载和安装。客户端与后端之间的持续交互会不断传输界面状态和用户输入，这可能影响响应速度。产品开发本身还需要将代码拆分到客户端和服务器之间；如果部分模块仍未拆分，动态界面可能出现延迟或卡顿。
Native模式如何工作？
新方法依赖一个名为IJent的代理。该代理在目标环境内部执行文件操作和进程操作，而不是通过9P或通用执行层转发这些操作。JetBrains称其为一个使用Rust编写的小型组件，从而减少了在WSL或容器内对Java或Kotlin等额外运行时依赖的需求。
IJent使用基于Stdio的传输层，该传输层具有可移植性，并且不需要开放防火墙端口；而在WSL中，Hyper-V套接字提供了更快的路径，尤其适合传输大量文件。由于文件系统操作在Linux环境本身内部执行，路径和符号链接的处理更接近原生Linux语义。当外部插件的文件操作经过IJent时，它们也能从中受益。
IJent与EelApi接口相连接。JetBrains设计该接口，是为了向平台开发者和插件作者隐藏本地环境与远程环境之间的差异。按照这一模型，同一段代码可以处理本地环境、WSL、Docker或Dev Container，而无需为每种环境添加专门逻辑。公司表示，IJent实现了EelApi接口并提供其实际功能。
测试结果如何？
JetBrains在一次冷启动项目打开测试中，对比了9P模式和IJent模式。测试项目为spring-framework，包含23个子项目和8,191个源文件。测量在Windows 11、WSL 2、Ubuntu 24.04和IntelliJ IDEA Ultimate 263.SNAPSHOT版本上进行，结果采用五次运行的中位数。
- 准备就绪：从18.5秒降至11.5秒，提升38%。
- 扫描项目树：从8.1秒降至3.7秒，减少54%。
- 文件索引：从10.8秒降至8.4秒，提升22%。
- 读取文件内容：从12.2秒降至5.7秒，减少53%。
公司提醒说，在同一测试中，一个仅包含少量文件的小型项目没有显示出可测量的差异。因此，实际收益主要体现在大型项目，或需要反复访问大量文件的工作流中。
这对开发者意味着什么？
最重要的变化是统一入口和推荐架构，而不是立即取消所有旧选项。在受支持的产品中直接打开WSL项目的用户会进入Native模式；而对于选择该路径，或需要客户端与后端分离模型的用户，Remote Development仍然有用。至于通过WSLg运行IDE本身，JetBrains表示这在技术上可行，但并非一流的受支持工作流，因为其中存在与图形、窗口管理和输入相关的限制，并且应用依赖Windows内部的Linux显示层。
已公布的结果显示，部分操作获得了明显改善，但测试范围仅限于特定项目、环境和版本。因此，这些数字并不能证明其在所有项目或插件中都始终占优。此外，新架构仍在逐步扩展到更多JetBrains产品，因此插件兼容性及其在不同环境中的行为仍值得关注。