“轻量开源版 IDEA 来了”,刚看到这句话的时候,我第一反应是:IDEA 什么时候能跟“轻量”沾边了?用它的这些年,启动慢、吃内存、索引一跑就是半天,这些都是老生常谈。后来把产品线捋了一遍才明白,大家说的其实就是 JetBrains 那条完全免费、基于开源协议的 IntelliJ IDEA Community Edition(社区版)。它跟旗舰版共享同一套核心引擎,却把大量企业级、全栈化的周边模块拆掉了,装完以后整个心理负担都小一圈。
这篇文章我不打算写成官方文档的复述,而是把社区版当一个独立产品来聊:它到底“轻”在哪些地方、安装时有什么坑、第一次启动该怎么配置、哪些旗舰版功能确实补不回来,最后再聊聊开源这件事对你我意味着什么。无论你是刚转 Java 的学生,还是被公司授权搞得头疼的开发者,这篇文章应该都能给你一个比较完整的参考。
1. 先把名字对上:这里说的“轻量开源版 IDEA”究竟是谁
1.1 社区版和旗舰版本来就是同一产品线的两张牌
先说清楚:IntelliJ IDEA 不是“一个软件”,而是一条产品线。最常见的是两个发布通道,一个是 IntelliJ IDEA Community Edition,另一个是 IntelliJ IDEA Ultimate Edition。前者开源、免费、以 Apache 2.0 协议分发,也就是大家口里的“轻量开源版”;后者是 JetBrains 的付费商业版本,带完整的企业级功能套件。
这里有个历史背景挺有意思。早在 2009 年,JetBrains 就把 IDEA 的核心代码以 Apache 2.0 协议公开了,之后社区版和旗舰版一直共享同一个核心代码库。也就是说,社区版并不是“功能被砍残的玩具”,而是同一个 IDEA 引擎换了一套功能组合。它依然保留了 Java、Kotlin、Groovy、Scala 的完整支持,也保留了 Git/SVN、Maven/Gradle、调试器、测试工具这些日常开发的核心能力。
我见过不少新手第一次打开官网,看到“Community”和“Ultimate”两个词就懵了,以为社区版只是给开源贡献者用的临时版本。其实不是,社区版是一个独立、长期维护、可以正常用于商业项目的开发工具。很多人担心的“免费版会不会用着用着突然关闭”,在 JetBrains 这种商业模式里基本不会发生,因为社区版承担的是用户培养和生态扩展的任务,它反而是公司整个产品体系里最重要的一块敲门砖。
1.2 “轻量”和“开源”到底体现在哪些指标上
“轻量”这个词需要放在正确的坐标系里理解。跟 VS Code 或者 Vim 比,IDEA Community Edition 一点也不轻;但跟旗舰版比,它的确轻了不少。
首先是安装包体积。社区版和旗舰版的安装包都是几百 MB 到 1GB 上下,基础核心没差多少,真正的差异在功能模块。旗舰版会带着 Spring Boot 内置支持、数据库工具、Docker/K8s、前端框架支持、应用服务器集成等一大堆模块;社区版这些默认都不带,所以“开箱时的功能面”完全是两回事。
其次是运行时的资源占用。同样一个 Java 项目,社区版索引范围更小、后台服务更少,内存占用通常会比旗舰版低一截。这不是玄学,是功能模块减少后带来的真实差异。但如果你开一堆大型项目,或者装了十几个插件,这个优势也会被消耗掉,所以后面我会专门讲配置层面的调优。
最后是开源协议。社区版使用 Apache 2.0 协议,这意味着你可以查看源码、修改源码、在保留版权声明的前提下自由分发,甚至用于商业项目。这一点在团队协作和企业合规场景里非常重要。很多公司对“开发工具是否允许用于商业开发”有严格审计,社区版恰好提供了一个完全没有授权风险的起点。
1.3 社区版到底适合谁,我心里有一条明确的分界线
根据我自己接触过的场景,社区版非常适合这几类人:第一,刚学 Java 或 Kotlin 的初学者,没必要为学习阶段付高昂授权费;第二,做纯 Java 后端、不需要深度前端联调的人;第三,需要参与开源项目,希望保持工具链完全合规的开发者;第四,在创业公司或者预算有限的小团队里,想在开发效率和质量之间找到平衡的人。
反过来,如果你每天的工作场景离不开数据库脚本、容器编排、Spring Cloud 的整套可视化工具,或者经常要写 Vue/React 前端页面,那旗舰版确实能省很多事情。但这不意味着社区版用不了,只是需要额外的工具配合,后面我会给出一套完整的替代方案。先说结论的话,我对社区版的态度是:对主流 Java 开发者来说,它不只是“能用”,而是“够用”且“够稳”。
2. 安装实操:三平台部署步骤与最容易忽略的权限坑
2.1 Windows:推荐用 Toolbox App,但别把安装路径想得太随意
Windows 上装 IntelliJ IDEA Community Edition 有两种主流方式:一是直接下载官网的安装包 exe,二是安装 JetBrains Toolbox App 这个集中管理工具。我更倾向于推荐 Toolbox,原因是它不光管理 IDEA,还能统一管理 DataGrip、PyCharm、GoLand,以后想装哪个装哪个,升级也方便。
如果是直接用 exe 安装,有一个小细节容易踩坑:默认安装路径通常在 C 盘,有些人图省事一路 Next,装完后 C 盘空间直接告急。社区版本身需要的地方并不大,但项目缓存、索引、插件全都往用户目录塞,C 盘小的话很容易被塞满。我的习惯是安装时手动把目录改到 D 盘或者另外一块固态硬盘,同时把后面会提到的 Gradle/Maven 仓库路径也迁移出去。
另外,Windows 用户装完以后,欢迎页会询问是否要创建桌面快捷方式、是否加入右键菜单。如果经常要用命令行打开项目,建议勾选“添加idea命令到 PATH”之类的选项。这样你在某个目录下打开终端直接敲idea .,就能快速把当前文件夹作为一个项目打开,效率很高。
2.2 macOS:先解决“已损坏”或“无法打开”的困惑,再把 JDK 分清楚
macOS 上第一次打开 IDEA Community 时,最常见的现象是系统提示“无法验证开发者”或者“该应用已损坏”。很多新手遇到这个提示就慌了,以为是下载出错。其实这只是 macOS 的 Gatekeeper 在拦你:如果你从官网下载 dmg 而不是通过 App Store 安装,系统会默认先检查签名,签名没问题但来源不在白名单里时,就会弹这个提示。
解决方式也不复杂,打开“系统设置”里的“隐私与安全性”,往下拉找到“安全性”区域,点击“仍然打开”即可。如果已经点了取消,再重新打开应用一次,系统会再次询问。这个机制我第一次用的时候也折腾了半天,后来才明白它针对的是“首次启动”,不是每次启动。
macOS 用户还有一个特别容易混淆的点:IDEA 社区版自带一个 JetBrains Runtime,也就是 JBR,它是用来跑 IDE 本身的。但项目编译用的 JDK 跟这个 JBR 不是一回事。你可以在项目结构里单独指定任何一个本地 JDK,或者让 IDEA 自动检测系统里安装的 JDK。千万不要图省事直接用 JBR 当项目 SDK,虽然多数时候也能编,但版本匹配出了问题很难排查。
2.3 Linux:tar.gz 解压就能用,但启动器要自己补
Linux 环境下的安装最“默认贴近社区版的调性”:下载 tar.gz 压缩包,解压到某个目录,直接跑脚本就行,没有安装向导,也没有注册表那种东西。我比较习惯放在/opt下,给整个目录加普通用户权限:
sudo tar -xzf ideaIC-2024.2.3.tar.gz -C /opt/ cd /opt/idea-IC-242.21829.142/bin sh idea.sh注意,不同版本的目录名不一样,具体以你解压出来的目录名为准。启动之后 IDEA 会在~/.config/JetBrains目录下生成配置,插件也会放在类似目录里,不需要 root 权限。
Linux 用户经常碰到的一个问题是:关掉终端后 IDEA 也跟着退出了。这时候你可以用nohup或者直接配置一个桌面快捷方式。我习惯手动在~/.local/share/applications/下创建一个.desktop文件,把启动命令写进去,这样就能在应用菜单里看到图标了。
cat > ~/.local/share/applications/idea.desktop <<EOF [Desktop Entry] Type=Application Name=IntelliJ IDEA Community Icon=/opt/idea-IC-242.21829.142/bin/idea.svg Exec=/opt/idea-IC-242.21829.142/bin/idea.sh %f Terminal=false EOF桌面环境不同,图标文件的后缀可能是.svg可能是.png,如果菜单里没图标,就用find /opt -name "*.svg"去查一下实际路径。这个细节看起来不起眼,但能省掉每次都要开终端启动的麻烦。
3. 第一次启动,建议把这些配置一次性设置到位
3.1 先分清“IDE 用哪个 JDK”和“项目用哪个 JDK”这两件事
很多人第一次用 IDEA 时,会在启动界面直接被一堆选项搞晕。最典型的误区就是把“IDE 启动需要的 JBR”和“项目编译用的 JDK”当成一回事。弄清楚这个,后面很多问题都会自动消失。
打开项目后,进入File→Project Structure→Project,这里的SDK才是项目编译用的 JDK。如果你的机器还没装 JDK,IDEA 欢迎页的New Project向导里可以让你选择一个已安装的 JDK 或直接下载。我现在的建议是优先选 LTS 版本,比如 JDK 17 或者 JDK 21,它们生态成熟、升级压力小,大多数框架都支持得很好。对于刚入门的人,不要追着 JDK 23、25 这种新版本跑,没必要为了新特性给自己制造兼容性麻烦。
至于 IDE 本身的 JBR,它在Help→About里能看到,平时基本不用手动管理。它负责的是 IDE 的 UI 和运行环境,项目代码怎么编译,它不掺和。搞混了这两个概念,最常见的问题就是项目里明明配了 JDK 21,结果编译时用了 JDK 17,报一些诡异的“不兼容”错误,查半天也查不到源头。
3.2 Maven/Gradle 的本地仓库和镜像配置,越早搞定越省心
IDEA Community 对 Maven 和 Gradle 的支持是完整的,但默认的仓库配置往往会让新人吃尽苦头。Maven 会把依赖下载到用户目录的.m2/repository下,Gradle 的缓存目录也在用户目录下,如果系统盘空间小,下载几百 MB 依赖后就会告急。
Maven 的配置在settings.xml,通常放在 Maven 安装目录的conf下,也可以在用户目录下建一个.m2/settings.xml。我个人的做法是把它单独指到一块数据盘上,同时按需配置镜像源:
<settings> <localRepository>/data/maven-repo</localRepository> <mirrors> <mirror> <id>aliyun</id> <mirrorOf>central</mirrorOf> <url>https://maven.aliyun.com/repository/public</url> </mirror> </mirrors> </settings>这里要注意,如果你的网络环境可以比较顺畅地访问中央仓库,镜像不是必须的。但一旦你发现某个依赖下载特别慢或者反复失败,配置一个合适的镜像源几乎能立刻解决。Gradle 也有类似的配置方式,它通过GRADLE_USER_HOME环境变量来指定缓存目录,同时可以在init.gradle里配置仓库优先级。
这类配置我建议在第一次启动项目时就做好,不要等到下载依赖等得烦躁了再回头折腾。因为 IDEA 的依赖解析结果是会缓存的,改完仓库配置后如果索引还残留旧信息,反而会出一些“找不到依赖”的误导性问题。
3.3 插件列表:哪些必装,哪些尽量别装
社区版自带的能力已经不少,但如果你想要更好的体验,插件这块我建议慎选,而不是贪多。我长期保留的插件只有几个:Lombok(Java 开发基本离不开)、SonarLint(边写代码边做静态检查)、Save Actions(自动格式化、优化导入)、中文语言包(给刚接触 IDEA 的人降低门槛)。
其他插件在我看来都没那么必要。尤其不要装一堆主题美化插件,也不要同时装多个功能重叠的插件,因为每个插件都会增加启动时的类加载和索引负担,装得越多,IDEA 越谈不上“轻量”。很多人说社区版也越来越卡,很多时候不是 IDE 的问题,是插件装太多了。IDE 的“轻”需要你配合做减法,而不是装完后继续把它塞成旗舰版。
另外,插件的更新不要太激进。社区版插件市场里的很多插件是个人开发者维护的,偶尔会有新版不兼容的情况。我曾经遇到一个代码检查插件更新后,把整个项目索引搞坏,最后只能禁用插件再重建索引。这个教训让我后来对插件更新都采取“迟几天再看反馈”的策略,而不是收到提醒就立刻点 Update。
4. “轻量”之后仍然有的性能负担:内存和索引的实际调优
4.1 任务管理器里那一堆 Java 进程到底都是谁
很多人第一次用 IDEA 时会被任务管理器吓到,满屏的 Java 进程,CPU 和内存忽高忽低,以为电脑中毒了。其实这是正常现象,因为 IDEA 是一个多进程架构,IDE 主进程、项目编译进程、语言服务器进程、索引进程可能同时存在。每个进程都有它自己的内存配置和生命周期,不能简单用“一个进程占多少内存”来判断 IDEA 是不是太吃资源。
社区版比旗舰版省内存,核心原因就是少了很多内嵌服务和插件。但如果你的项目很大,仍有可能会看到 Gradle Daemon 常驻、索引进程频繁活动。遇到这种情况,先别急着换 IDE,先通过Help→Change Memory Settings调整 IDE 自身的内存堆大小,再看构建脚本里的 JVM 参数是否有必要开得那么高。
4.2 堆内存、构建内存和系统内存怎么分配才科学
“堆内存”这个词很容易把人绕晕。简单说,IDEA 主程序跑在一个 JVM 里,它的堆内存由-Xmx参数控制;Gradle 或 Maven 在构建项目时,又会拉起另一个 JVM,它的堆内存通常要在构建工具的配置文件里单独设置。
我个人的经验是:8GB 内存的机器,给 IDEA 设置-Xmx2g,构建工具再给 1GB 左右,整体不会太吃紧;16GB 内存的机器,IDEA 可以给到-Xmx3g或-Xmx4g,构建工具给 2GB;再往上就没什么必要了,IDEA 不是你把堆内存调越大就越流畅,反而可能因为 GC 暂停时间变得更长,主观体感还变差。
修改路径是Help→Change Memory Settings,填完以后需要重启 IDE。如果你对这个参数已经很熟悉,也可以直接改idea.vmoptions文件,它位于 IDE 配置目录下,里面可以设置-Xms和-Xmx。新手不建议手改文件,直接在图形界面里操作最稳妥。
4.3 真正影响体验的经常不是内存,而是索引
我见过不少机器内存很大,但 IDEA 用起来还是卡,卡点通常不在内存,而在索引。IDEA 为了提供跳转、补全、重构这些能力,启动时会扫描项目文件并建立索引,文件越多、目录越复杂,索引时间越长,建立索引过程中 CPU 和磁盘 IO 都会很高。
想要让索引不失控,最重要的手段是“排除目录”。在Project Structure→Modules→Sources面板里,可以把target、build、.gradle、node_modules、out这样的目录标记为Excluded。排除之后,IDEA 就不会链接文件。对于大型工程,这一步能带来质变;如果项目早就建好了,我先排除再少量缓存清理,能快很多。
另一个常用操作是File→Invalidate Caches,选择清空并重建索引。当升级版本后索引损坏、代码跳转错乱时,这个操作基本能救回来。需要注意的是,重建索引会重新扫描整个项目,在超大项目上需要一段时间,别在中途强杀进程,不然容易把索引文件弄坏。
4.4 我自己的环境配置参考
我现在的主力开发机是 32GB 内存,平时同时开着 IDEA Community、DBeaver、一个浏览器和若干终端,IDEA 的-Xmx我限定在 4GB,Gradle 构建内存限定在 2GB。项目规模是中等偏大的微服务代码仓库,全部索引后内存占用稳定在 2GB 左右,日常写代码几乎感觉不到延迟。
我也在 8GB 内存的老笔记本上装过同样的社区版,老老实实把-Xmx降到 2GB,排除目录做好之后,写一个单体 Spring Boot 项目仍然很流畅。关键就在于不要听别人说“设置越大越好”,要根据自己的内存总量和项目规模来定。
5. 社区版和旗舰版的功能分界,以及哪些缺失能靠工具补
5.1 先看一张对照表
这是很多人最关心的部分,社区版到底少了什么。我根据自己的使用体验整理了一份对照表,不需要把它当成绝对权威,但可以作为判断“能否迁移到社区版”的参考:
| 功能 | 社区版 | 旗舰版 | 我的实际评价 |
|---|---|---|---|
| Java/Kotlin/Groovy/Scala 核心支持 | 完整 | 完整 | 日常开发体验几乎无差别 |
| Spring / Spring Boot | 基础代码提示可用 | 内置完整工具链 | 缺少一键创建工程和 Bean 可视化导航,但写纯后端仍可接受 |
| 数据库工具 | 无内置 | 完整 Database 面板 | 用 DBeaver 替代即可 |
| Docker/K8s | 无内置 | 部署与调试面板 | 终端命令完全能解决 |
| JavaScript/TypeScript/Vue/React | 基础语法高亮 | 完整前端开发工具 | 前端工作量大时建议交给 VS Code |
| 远程开发/Gateway | 有限支持 | 更完善 | 按需选择 |
表格列完你会发现,社区版最主要缺的其实是“全栈开发的一站式体验”,而不是“Java 开发的核心能力”。如果你的项目恰好以纯 Java 后端为主,很多东西缺了你根本感知不到。
5.2 我用社区版时采用的替代工具组合
既然缺了,那就别硬撑,用一个顺手的外部工具补上即可:
数据库方面,我用 DBeaver 已经很多年,它开源免费、支持几乎所有主流数据库,还能直接读连接信息,日常写 SQL、看表结构、导数据都比 IDEA 自带的数据库面板顺手。前端方面,我一般会配合 VS Code 打开前端工程,专注于 Vue 或 React 页面,IDEA 只负责后端代码。容器的部署直接用终端,写 docker-compose 文件、看日志,这些操作并不需要 IDE 有 Docker 面板。
插件方面,有些早期的旗舰级功能其实能在社区版上靠开源插件弥补。不过我的经验是,不要想着把一个毫不相关的插件拿来硬凑,值不值得要看它是否稳定。我见过有人为了让社区版支持某数据库,装了个第三方插件,结果每次版本升级都出问题。与其这样,不如把专业的事情交给专业工具。
5.3 合规性也是“开源版”很值钱的地方
这块我想重点说一句:社区版是官方完全免费、开源的版本,你不需要研究任何破解、激活、密钥之类的东西。对个人用户来说,省的是钱;对团队和企业来说,省的是合规风险。很多公司做软件资产审计时,对商业软件的授权数量、使用范围盯得很严,用社区版能从根本上避开这些灰色地带。
当然,开源免费不意味着可以随意把 JetBrains 商标拿来商用。Apache 2.0 授权的是代码本身,这点在前面提过。我的建议是,如果你打算基于社区版做一些分发或改造,那就认真阅读一下授权文件,搞清楚“哪些能做、哪些必须保留声明”这类基础问题,别等到出了问题再回头看。
6. 换到社区版之后的工作流复盘与踩坑记录
6.1 我为什么从旗舰版换到社区版
我之前用旗舰版的时间不短,后来换到社区版并不是因为授权费用,而是因为我的工作流发生了明显变化。以前我需要频繁在 Java 后端、数据库、前端工程、Docker 容器之间来回切换,旗舰版的一体化界面确实方便。但后来前端工作拆分给专门的同事,数据库也统一用外部客户端,旗舰版很多功能对我来说就成了“安装即吃灰”的模块。
换到社区版之后,最明显的感觉就是干净。没有那么多内置服务在后台活跃,打开项目的索引范围更小,整体响应更干脆。很多人担心从旗舰版降级到社区版会有很强的“缺失感”,实际情况是,只要你不是天天用那些高级功能,适应期可能只有两三天。真正的坑隐藏在配置细节里,下面列几个我踩过的。
6.2 排查一:构建内存溢出,锅常不在 IDE 而在 Gradle
刚换过来没几天,我对一个遗留项目执行构建时直接报OutOfMemoryError。第一反应是社区版是不是有什么限制,后来查了一下才发现是 Gradle 默认的 JVM 内存太小。Gradle 的构建进程是独立于 IDE 的,要单独设置。
在项目根目录的gradle.properties里加入下面的配置即可:
org.gradle.jvmargs=-Xmx2048m这个配置拖了很久才生效,因为 Gradle Daemon 会常驻后台,改完必须停止已有进程再重新构建。你可以用./gradlew --stop停掉后台进程,再执行构建命令。这个坑跟 IDE 版本没有太大关系,但确实在切换环境后容易被误判成“社区版能力不足”。
6.3 排查二:IDEA 缓存越积越大,磁盘空间莫名消失
用了一段时间社区版后,我开始频繁收到系统磁盘空间告警。排查了一圈才发现,IDEA 的索引缓存和本地历史都存放在用户目录下的配置目录里,长时间不清会膨胀得很快。尤其是参与过几个大型项目之后,缓存体积可能轻松超过几 GB。
处理方式是在File→Invalidate Caches里选择清理,但如果只是磁盘紧张,我更建议大家定期清理~/.config/JetBrains或用户目录对应的配置。新建一个固定目录用来存放索引缓存,平时不要动,隔一两个月手动清理旧的版本文件夹就行。IDEA 升级后,旧版本的配置目录不会自动删除,这个手动清理很有必要。
6.4 排查三:控制台输出中文乱码,源头居然在项目编码
有一次我在社区版里跑单元测试,控制台中文直接变成乱码,当时我以为又是工具链的问题。后来检查才发现,项目的源文件是 UTF-8 编码,但 JVM 运行参数默认用了系统编码。在运行配置里的 VM options 加上-Dfile.encoding=UTF-8,问题就解决了。
这其实跟社区版没有关系,旗舰版同样会遇到,只不过因为在旧环境里早就配好了,换到新环境才会暴露出来。遇到乱码问题,先查三处:源文件编码、IDE 的全局编码设置、运行配置里的 VM options,不要一头扎进插件市场找“编码修复插件”,那只会把事情搞复杂。
6.5 什么情况下我仍建议留旗舰版
虽然我自己用社区版很顺利,但我不建议所有人盲目跟进。如果你的日常开发里“同时开一个 Java 后端工程、一个前端工程、一个数据库连接列表,在一套 IDE 界面里全搞定”是你的刚需,那旗舰版确实值这个价。又或者你在做 Spring Cloud 微服务治理,需要大量依赖可视化面板,社区版这种“外部工具拼装”的方案会增加很多切来切去的成本。
说到底,选哪个版本是在选“工作流形态”,而不是在选“谁更厉害”。对我这种愿意把专业工具拆分的人来说,社区版很舒服;对追求一体化操作体验的人来说,付费旗舰版反而是更高效率的选择。
7. 开源版本的意义:源码、插件与自行构建的可能性
7.1 通过源码仓库了解 IDE 真正做了什么
社区版是开源的,这意味着你不需要靠 Google 和零散的博客去猜测 IDEA 内部是怎么工作的,直接去源码里找答案就行。JetBrains 在 GitHub 上放了 IntelliJ Community 的代码仓库,里面包括核心引擎、编辑器、版本控制、构建工具集成等大量模块。
我最早看这些源码,主要是想搞清楚“为什么某些情况下补全会卡顿”。后来发现,与其外部猜测排序逻辑,不如直接看编辑器模块的代码结构。虽然完整的调试过程比较复杂,但光是阅读核心模块的代码布局,就能帮你理解一个大型 IDE 的插件化体系是如何组织起来的。这种收获,对于一个做开源项目的开发者来说,比单纯“使用软件”要深得多。
7.2 自己编译一版 IDEA,体验一次就好
网上有一种玩法叫“自己构建一版 IntelliJ IDEA”,听起来很极客,实际做起来非常费时。官方源码需要 Gradle 构建,先要准备好对应版本的 JDK,还要下载上千个依赖库,整个编译过程可能在几十分钟到几个小时不等,内存不够还容易中途失败。
我自己试过一次,主要目的不是要“换个名字”,而是为了理解它的构建过程和模块裁剪原理。结论是:对普通开发者来说,自己编译一版 IDEA 的性价比很低,除非你要做深度的定制或二次开发,否则直接下载官方构建版本就行。但这个过程能让你直观感受到“所谓轻量版,其实是插件和模块组合不同,而不是核心代码有另一套”。
7.3 更现实的参与方式是写插件
比起编译整个 IDE,参与开源社区更现实的路径是写插件。IDEA 的插件开发框架比较成熟,你可以在社区版里直接新建一个 Plugin 项目,通过扩展点实现自定义菜单、代码检查、语言支持等功能。这样既能满足你自己的特定需求,也能把成果发布到插件市场给别人用。
社区版在这儿的价值就是降低了门槛:你不需要购买旗舰版就能完整开发、调试、打包插件。而且插件开发工程本身就是 Java/Kotlin 项目,等于用 IDEA 开发 IDEA 插件,算是一个挺有意思的闭源与循环。很多知名第三方插件最初的作者,也都是从个人痛点开始的。
讲到这里,我其实已经不太在乎“轻量”这个标签到底代表多少 MB 内存了。它在我的实际工作里,更多意味着“不需要为了功能模块交税,也不需要为了让每个功能都出现在同一个窗口里而牺牲整体响应”。如果你也在评估要不要切换,我的建议是:先列一份自己的常用功能清单,再看官方功能对照表,不要凭感觉选版本。工具是拿来产出代码的,不是拿来集邮的。