JetBrains IDE 中 WSL 支持的演进
内容提要
JetBrains IDE 自2026.2版起，推荐以“原生模式”支持WSL，通过轻量代理IJent处理Linux文件与进程，取代旧有的9P协议和远程开发方案。此模式提升性能，冷启动大型项目提速38%，并统一了WSL、Docker等非本地环境的开发体验。
延伸解读
为何弃用9P协议
旧方案依赖9P协议访问WSL文件系统，但存在符号链接支持不完整、微软Defender扫描导致读取延迟、大量小文件操作时吞吐量下降等问题。这些缺陷直接影响依赖符号链接的工作流（如pnpm工作区、Python虚拟环境），并拖慢索引等核心操作。新方案通过IJent代理在WSL内部执行文件操作，绕开9P，从而获得正确的Linux语义和更优性能。
原生模式与远程开发的区别
远程开发将IDE后端放入WSL，需额外下载约2GB组件，且客户端与后端间持续通信带来性能开销。原生模式则保持IDE为Windows应用，仅通过轻量代理IJent处理Linux文件与进程，安装更轻、延迟更低。虽然两者都采用客户端-服务器模型，但原生模式的服务器端更薄，且同一架构可复用于Docker和Dev Containers，统一了非本地环境的开发体验。
性能提升的适用场景
官方基准测试显示，冷启动大型项目（如spring-framework，8191个源文件）时，原生模式比9P模式总等待时间减少38%，扫描项目树、索引、读取文件内容均有显著提升。但小项目差异不明显。因此，性能优势主要体现在大型项目或文件操作密集的场景，小项目用户可能感受不到明显变化。
Q&A
JetBrains IDE 从哪个版本开始推荐使用原生模式支持 WSL？
从 2026.2 版本开始，JetBrains IDE 推荐使用原生模式支持 WSL。
JetBrains IDE 中原生模式是如何工作的？
原生模式下，IDE 本身作为 Windows 应用程序运行，而在 WSL 内部有一个轻量代理 IJent 负责处理文件访问和进程执行。
JetBrains IDE 之前支持 WSL 的几种方式分别是什么？
之前支持 WSL 的方式包括：通过 9P 协议进行文件访问、使用 WSLg 在 WSL 内运行 IDE、以及远程开发模式。
9P 协议在 WSL 支持中存在哪些问题？
9P 协议存在符号链接处理受限、Microsoft Defender 扫描导致文件读取延迟、以及文件访问延迟和吞吐量下降等问题。
为什么 JetBrains 不推荐使用 WSLg 方式运行 IDE？
因为 WSLg 方式下 IDE 作为 Linux GUI 应用运行，存在渲染、弹窗、窗口管理、输入法等方面的限制，且没有提供专门的产品支持和安装流程。
远程开发模式在 WSL 支持中有哪些缺点？
远程开发模式需要下载和安装约 2 GB 的后端，且客户端与后端之间的通信会带来性能开销，同时增加了开发维护成本。
IJent 代理是用什么语言实现的？为什么选择该语言？
IJent 代理使用 Rust 实现，因为 Rust 可以使可执行文件保持轻量，并且避免引入额外的运行时依赖。
EelApi 的作用是什么？
EelApi 是一个 API，用于抽象本地和远程环境的差异，使 IDE 和插件无需关心代码运行在本地、WSL、Docker 还是 Dev Container 中。
原生模式相比 9P 模式在性能上有哪些提升？
根据测试，冷启动大型项目时，原生模式比 9P 模式快 38%，扫描项目树快 54%，索引文件快 22%，读取文件内容快 53%。
原生模式除了 WSL 还适用于哪些环境？
原生模式同样适用于 Docker 和 Dev Containers，因为 IJent 代理可以部署在这些环境中。
