1. 先搞清楚编辑器的江湖格局2021年年中的时候也就是5月份那阵子编辑器圈子的版图其实已经相对稳定了。说“稳定”不是说没竞争而是每个工具在用户心里基本都有了明确标签VS Code 是当红炸子鸡Sublime 是轻量刺客Vim 是终极信仰JetBrains 系是重装主力Atom 是慢慢失宠的前朝遗老Notepad 则是 Windows 老兵的怀旧选择。我当时刚好做了一次比较完整的编辑器选型调研趁着这个机会把这篇文章整理出来把各家主流的代表、适用场景、优缺点以及我实际使用中踩过的坑一并补上。很多人选编辑器时容易陷入两个极端一种是“永远在尝鲜”听说哪款好就换哪款结果一天到晚在迁移配置另一种是“一条道走到黑”明明工具已经严重拖累效率还死活不肯换。我个人的观点一直是——编辑器没有绝对的好只有适不适合你当前的场景。但前提条件是你得先把市面上主流选手的真实底细摸清楚才好做判断。这篇内容主要以 2021 年年中的视角来做横向盘点同时会把一些核心操作思路和配置技巧也放进来方便你拿来做选型参考。就算你眼下不打算换编辑器看看各家设计的理念差异也能反哺你当下工具的使用习惯至少能帮你发现一些平时忽略掉的功能。我给自己定了个框架先按“阵营”把主流编辑器分成四大类——轻量级文本编辑器、全功能 IDE、终端派编辑器、云端/协作型编辑器然后再逐个拆解它们的定位、优势和劣势。这样不会变成一篇纯粹罗列功能说明书的枯燥内容而是真的能理清“我该用哪个”这条主线。2. 轻量级阵营Sublime Text、VS Code、Atom 与 Notepad轻量级编辑器的核心卖点是“快”和“轻”但这里说的“轻”其实分层次。有的是启动快有的是内存占用低有的是安装包小还有的是打开大文件不卡。它们各自优化的方向不太一样选的时候要看你在意哪个维度。2.1 当时最抢眼的 VS Code生态无人能敌2021 年那会儿VS Code 已经连续几年蝉联各种开发者调查的“最受欢迎编辑器”榜首了。它基于 Electron 技术框架打造本质上是运行在 Chromium 内核里的 Web 应用所以界面渲染能力很强而且跨平台一致性好。Windows、macOS、Linux 上长得一模一样团队的协作成本能明显降下来。VS Code 最大的护城河是插件市场。我当时统计了一下Extensions Marketplace 里的插件数量轻松破万无论你写 Python、Go、Rust、前端三件套还是 Kubernetes YAML总能找到对应的语言支持、Lint、格式化、调试配置。而且它的 IntelliSense智能补全是基于语言服务协议LSP做的这让它不只是“花哨记事本”而是无限接近 IDE 的存在。我实际体验中印象比较深的是它的调试器。以前写 Node.js 或者 Python 脚本时我习惯额外开一个调试工具但 VS Code 里面直接按 F5 就能启动调试会话断点、变量监视、调用堆栈全部集成在同一个界面里这确实减少了很多来回切换的时间损耗。还有它的“全局搜索”功能大项目里搜关键词响应速度相当快打开大文件虽然偶尔会有些卡顿但整体仍在可接受范围内。不过Electron 的先天劣势也躲不掉内存和 CPU 占用偏高启动速度比原生应用慢不少。我实际跑过一台 8GB 内存的普通笔记本电脑同时开 VS Code、浏览器、几个终端窗口内存会明显吃紧。如果你电脑配置不高需要在使用前做点减负——比如关闭不需要的扩展、调节搜索排除目录、用工作区而非直接拖文件夹打开。2.2 老牌轻量王者 Sublime Text性能党的心头好Sublime Text 在 2021 年仍然是我心中“性能党首选”之一尤其是它打开超大文件的流畅度很多编辑器都比不了。它用 C 写的底层界面响应非常跟手启动速度几乎是瞬间完成而且它没有 Electron 那套东西占用内存小很多。从 2017 年发布 Sublime Text 3 之后它一直是很多运维、后端工程师手里的常驻工具。Sublime 的核心操作逻辑是“命令面板”CtrlShiftP。这玩意儿用熟了之后你几乎可以不碰鼠标所有功能都可以通过模糊匹配调出来装插件、切语法、改缩进、执行构建全都能在命令面板里完成。它还有一个特色是一次布局里拆多个窗格Grid Layout对于同时对比多个文件非常方便这在处理配置文件比对时帮了我不少忙。但它也有明显短板插件生态和 VS Code 比少了两个量级语言智能补全大多要靠 Package Control 里的社区方案有时候需要手动改配置内置的 Git 集成相当弱通常要配合终端或外部工具还有一个经常被吐槽的点是 License 弹窗——虽然可以无限期试用但时不时会弹一下商业使用还是需要购买授权的。2.3 曾经的明星 Atom慢慢淡出主舞台把 Atom 放在这里更多的是为了做历史参照系。Atom 也是 GitHub 出品的 Electron 编辑器曾经在一段时间内热度非常高很多人是被它的高颜值和高度可定制性吸引入坑的。在 2021 年Atom 还是有一批忠实用户但整体新用户增长已经明显放缓。Atom 的问题主要在于性能。同样是 Electron 底座它在启动速度和响应上比 VS Code 差不少尤其是装了十几个插件之后那种“卡顿感”会真实地影响到日常心情。项目如果稍微大一点Atom 在查找引用、全局搜索这些操作上会有明显延迟。如果说你现在的电脑配置一般又想找一款界面顺眼的编辑器我不太建议选择 Atom——除非你真的大量使用它的“分屏编辑”和“Teletype 协作”功能该功能当时仍在实验阶段。从后来的趋势看GitHub 官方也已经把开发重心转向了 VS CodeAtom 的停更信息其实在社区里早有预兆只是在 2021 年 5 月份这个时间窗口它仍然出现在不少选型文档里。这里我顺带提一句做选型调研时不要只看眼前的下载量还要看看项目维护的活跃度、版本迭代的节奏这才是更长期的判断依据。2.4 Windows 老兵 Notepad小而快但有局限Notepad 在国内的老牌 Windows 用户里认同度很高。它基于 Scintilla 组件开发安装包只有几兆启动快得离谱对电脑配置几乎没有要求。很多运维老哥的习惯是系统里装一个 Notepad改个 hosts、看个日志、写个临时脚本双击就能打开不需要等任何加载动画。但它的缺陷也很明确首先它只支持 Windows如果你偶尔用 macOS 或者 Linux就得找替代品比如 Notepad 的很多功能可以靠 VS Code 替代其次它的智能提示和代码导航能力比现代化编辑器弱很多写大型项目会感觉比较“原始”。另外它的插件机制偏传统虽然有 Plugin Manager但整体丰富度和维护活跃度都一般。2021 年那会儿我也在一些团队环境里见过强制安装 Notepad 的情况理由是“大家都用这个处理文本方便”。但实际上如果团队里有前端或者后端在写代码长期用 Notepad 确实会很痛苦。我的建议是它可以作为 Windows 下的“备用记事本”存在但最好不要作为主力开发工具尤其是当你需要调试、重构、版本管理集成这些能力的时候。综合来看轻量级阵营选型时可以按下面这个思路来判断需求维度推荐选择核心理由跨平台、生态丰富、要调试VS Code插件市场最大语言服务完善极度追求启动速度和低内存Sublime Text原生性能打开大文件快老 Windows 环境、轻量改文本Notepad免安装绿色双击即用追求高颜值与极简风格Atom当时仍可选界面美观但性能是短板3. 全功能 IDE 阵营JetBrains 全家桶与 Eclipse 系列轻量级编辑器解决的是“快速编写与浏览”当你需要应对大型工程、深度重构、复杂调试、性能分析、数据库面板、容器编排等一体化能力时IDE 依然不可替代。这个阵营的典型代表就是 JetBrains 系列以及 Java 世界里根基深厚的 Eclipse 系。3.1 JetBrains 系列语言上下文感知的天花板JetBrains 在 2021 年的产品线已经铺得很广IntelliJ IDEA 主攻 JavaPyCharm 主攻 PythonWebStorm 主攻前端开发GoLand 主攻 Go还有面向数据库的 DataGrip面向多语言协作的 Fleet 也在规划之中。它们共享同一套底层平台IntelliJ Platform所以只要你熟悉了其中一个其他产品上手成本会非常低。JetBrains 系最打动我的是它“深度理解代码”的能力。它不仅仅是基于正则匹配做关键字高亮而是真的会构建项目的语法树和引用关系。比如重命名一个变量时它能自动识别同名的局部变量和外部变量精确地只改该改的地方又比如在 Java 里跳转到接口实现类或者在 Python 里快速定位某个方法的定义——它的索引机制非常高效日常代码导航体验几乎是行云流水。IDE 的代价自然是“重”。以 IntelliJ IDEA 为例首次导入一个大型 Maven 项目时索引构建可能需要几分钟时间期间 CPU 和内存占用非常高。Android Studio 也是基于 IDEA 内核开发的大家应该对这种感觉不陌生——打开工程后就听着风扇转。所以如果你只是写一些小脚本、学习 Demo用 IDE 属于杀鸡用牛刀纯属给自己机器加负担。JetBrains 系还有一个特色是内置了很多“周边能力”数据库工具、HTTP Client、终端模拟器、Docker 插件、远程开发。它们把原本需要切换多个软件做的事尽量在同一个界面里完成。对我个人来说写全栈项目时用一个 WebStorm 或 IntelliJ IDEA 就够了基本不需要额外开数据库管理软件和 API 调试工具。价格方面JetBrains 是收费的按年订阅。当时它也提供针对开源开发者、学生、教育工作者等场景的免费授权如果你是符合条件的用户值得去申请。如果团队预算有限也可以考虑只给后端同事统一采购前端继续用 VS Code各取所长。3.2 EclipseJava 老牌劲旅的挣扎与实用场景Eclipse 在整个 Java 开发史上的地位毋庸置疑。很多老一代 Java 工程师的职业生涯都是从 Eclipse 起步的它的插件体系OSGi 架构曾经极其辉煌。但到了 2021 年Eclipse 在开发者社区的声量明显下降用户增长也主要是传统企业和教学场景带动。Eclipse 的优缺点非常清晰优点是完全开源免费跨平台插件接口开放很多厂商基于它定制自己的 IDE比如早期的 STS、Hibernate Tools 等缺点是架构偏老界面视觉和交互体验比 JetBrains 系粗糙内置的 Maven/Gradle 支持不如 IDEA 顺手Git 集成也比较“直男操作”。如果你是在校学生或者公司有强制要求使用 Eclipse那也没什么问题——它依然能完成 80% 的 Java 开发需求。但如果在选型阶段Java 团队我更推荐直接用 IntelliJ IDEA 社区版或付费版因为日常维护代码的效率差距是能感知到的。Eclipse 最大的生存空间其实在“嵌入式开发”和“特定企业生态”里比如某些厂商提供的 SDK 和插件只做了 Eclipse 版本这时你就没法为了追求好用而随意换工具了。4. 终端派编辑器Vim 与 Emacs 的两种信仰终端派编辑器是一条独特的路线。它们没有界面那些花哨元素一切操作都围绕键盘展开学习曲线陡峭但一旦掌握效率提升非常明显。这个阵营的两位代表 Vim 和 Emacs理念几乎是背道而驰的。4.1 Vim模式化输入练成肌肉记忆Vim 的核心设计是“模式编辑”。它把键盘输入分成普通模式、插入模式、可视模式、命令模式等在不同模式下同一个按键的功能完全不同。第一次接触的人往往感觉莫名其妙——按个 i 才能输入文字按 Esc 又回到普通模式光标移动用 h/j/k/l 而不是方向键。但当你习惯了这种操作逻辑后写代码时“移动光标、选中块、复制粘贴、替换文本”都不需要离开主键盘区手指移动距离大幅减少。Vim 的配置体系也很有特色。用户目录下的 .vimrc 文件可以定义快捷键、安装插件通过 Vundle、vim-plug 等插件管理器、定制主题。2021 年时Neovim 已经成为 Vim 社区的一个重要分支它重构了内部架构让异步执行和内置终端支持变得更好很多人也因此重新关注起终端编辑。我早期用 Vim 时也走过弯路一上来就想配出“IDE 一样的体验”装了几十个插件结果维护成本比写代码还高。后来我认清了一个道理——Vim 最适合的场景是“快速编辑服务器配置文件、在远程终端里改代码、写 Git commit message、处理临时文本”而复杂项目的主力开发可以把 Vim 的按键绑定作为插件装到 VS Code 或 IDE 里而不是真的用纯 Vim 去完成全部工作。这个思路很实用在 VS Code 里装 Vim 插件你既能享受到现代化编辑器的补全、调试、代码导航能力又能用 Vim 的按键习惯快速操作两全其美。许多 JetBrains 系 IDE 也有对应的 Vim 模拟插件IdeaVim用法类似。愿意付出学习成本的人这套组合的收益是非常可观的。4.2 Emacs可编程编辑器一切皆可定制Emacs 的历史比 Vim 还要久远它的核心理念是“Everything is a buffer”界面上的任何内容本质上都是文本缓冲区而且它内嵌了一个 Lisp 解释器理论上你可以用 Lisp 语言把编辑器改造成任何形态。这种高度的可扩展性让它在一些技术极客和学术圈子里拥有稳固的社群。但 Emacs 的问题也很明显默认配置上手难度极高新手连退出都搞不清快捷键Ctrlx Ctrlc 是退出更不用说扩展包的安装与加载机制。Evil 模式可以让你用 Vim 的按键习惯操作 Emacs算是融合了两个世界但整体学习曲线依然很陡。如果你对“用编辑器写程序来控制编辑器”这件事本身不感兴趣那我不太建议把 Emacs 作为日常主力。它的价值更多体现在方法论层面的启发——编辑器不只是一个输入工具它甚至可以说是一个操作系统的前端壳。对于想深入理解编辑器设计哲学的人来说Emacs 是一本很值得翻阅的教材。5. 云上和协作编辑器的新边疆2021 年值得关注的一个方向是云编辑器和对协作能力的重视。过去我们习惯“本地装环境代码在本地跑”但云开发的出现改变了这个模式。5.1 在线编辑器与应用场景GitHub 的 Codespaces、Gitpod 这类云端开发环境再加上一些轻量级的基于 Web 的 IDE如 StackBlitz、CodeSandbox让“浏览器里写代码”变得可行。它们的核心思路是云端提供统一的开发环境本地只负责浏览器渲染与交互配置和环境依赖都可以在云端容器里预先构建。这种方式在大型团队里尤其有吸引力——新成员入职后不需要折腾一整天“本地环境搭建”打开浏览器就能有可用的开发环境。我当时尝试过用 Codespaces 跑一个前后端分离的项目初始化体验已经相当顺畅仓库里有 Dockerfile 和 devcontainer 配置的话云端环境会自动拉起数据库、缓存、依赖包和本地效果一致。不过网络条件对体验影响比较大在国内访问这类服务的稳定性可能会有波动这部分我当时没有深入测具体以你自己实际网络环境为准。如果你更多是写前端 Demo、临时验证一段代码CodeSandbox 这类轻量网页编辑器也值得熟悉。它们内置了常用的框架模板改动可以实时预览还能自动生成分享链接。这种“零配置、即开即用”的体验在某些教学、分享场景下比本地编辑器便捷很多。5.2 多人在线协作的协作体验过去“多人同时改一个文件”在传统编辑器里几乎不敢想象一般只能靠版本管理工具Git来解决冲突。现在部分在线编辑器和 VS Code 的 Live Share 扩展可以实现“结对编程”式协作不同的人同时查看同一个文件一个人写代码另一个人光标实时跟随甚至共享调试会话和终端。这对远程办公、技术辅导、代码评审都有实实在在的帮助。我在实际团队协作中用过 Live Share体验是“秒级的同步”几乎没有明显延迟。它的定位不是替代 Git而是在你“需要即时讨论一段代码”时省去反复推送分支、拉取代码、打开 Diff 的环节。这个工具在 2021 年已经有较成熟的表现如果你团队里有远程办公的需求可以纳入考虑范围。6. 真实项目里的选型组合与配置实战前面说了那么多对比关键是落地。这里我用几个真实工作场景来演示“怎么选编辑器组合”并附上一些可复现的配置实操。6.1 后端微服务团队怎么配团队如果主要是 Java 生态我建议主力 IDE 用 IntelliJ IDEA。在 IDEA 里我通常会做三个关键调整把内存堆设置调大在 Help Change Memory Settings 里根据机器配置把堆内存从默认的 2048MB 适当调高。我常在 16GB 内存的机器上调到 4096MB大项目索引速度会有明显改善。开启“按需导入”和“自动导入”功能减少手动管理 import 的琐碎感。配置统一代码风格文件.editorconfig 或 IDE 的 Code Style Scheme保证团队提交代码格式一致减少没必要的格式冲突。如果团队同时要处理一些轻量级脚本、运维配置可以搭配 VS Code 作为辅助工具专门用来快速改 YAML、JSON、Shell。这样疾如风的工具做轻活重火力的 IDE 做重活各司其职。6.2 前端全栈开发怎么选前端人的主阵地其实 VS Code 就很能打内置的调试器可以直接调试浏览器里的代码还有 ESLint、Prettier、Tailwind 提示等插件。加上“代码片段”功能可以把高频模板比如 React 组件结构一键补全效率提升很直接。如果你的前端项目还涉及 Node.js 后端或者你需要在同一个工具里同时看数据库、调接口、跑脚本用 WebStorm 会更爽。它把 HTTP Client类似 Postman、数据库工具、终端全塞在编辑器里可以少装很多独立软件。我个人的常用组合是主力 WebStorm 写工程收尾做快速演示或临时改文件时开 VS Code。需要强调的是梳理好“主力”与“辅助”比不断切换工具更重要。因为每款编辑器都有自己的缓存、索引机制和插件体系频繁切换往往会让你的注意力碎片化。上面这套思路可以参考这首打油诗我朋友编的VSC 补全真方便Sublime 打开大文件JetBrains 智能不一般Vim 远程改配置还算稳。虽然不完全严谨但对于快速向新同事解释选型差异还挺好用的。7. 我的配置片段与日常避坑心得有些配置细节对新手来说不容易找到这里我放几个自己正在用的片段并说明为什么这么配。7.1 VS Code 的 settings.json 精简优化我个人偏好关闭“编辑器动画”和“像素对齐”之类对性能影响较大但对实际编码帮助很小的特效并在搜索时排除 node_modules、dist 这类明显不需要搜的目录{ editor.fontSize: 15, editor.formatOnSave: true, editor.minimap.enabled: false, files.exclude: { **/node_modules: true, **/dist: true }, search.exclude: { **/node_modules: true, **/dist: true }, editor.renderWhitespace: selection, git.autofetch: true }这几个配置的核心思路就是减少视觉干扰、去掉无效搜索、保存时自动格式化、让 Git 状态自动保持最新。实测下来对大项目的日常体验提升很明显。7.2 Sublime Text 打开超大日志的优化如果你经常需要查看几百 MB 甚至上 GB 的日志文件Sublime Text 是最顺手的工具之一。用之前可以在设置里加一行highlight_line: false, word_wrap: false这样能减少渲染负担在超大文件里滚动时能明显感觉到更跟手。如果在打开文件后还是卡可以进 Preferences Settings 关闭自动缩进检测或者改用二进制/纯文本模式查看。7.3 Vim 小白快速配置如果你刚开始接触 Vim我建议不要急着上插件全家桶先把最基本的 .vimrc 配置写好set number set relativenumber set tabstop4 set shiftwidth4 set expandtab syntax on filetype plugin indent on set clipboardunnamedplus这段配置解决的问题很直接显示行号、相对行号方便跳转、统一缩进为空格、打开语法高亮、共享系统剪贴板。先把这些基础体验稳下来再去玩插件不迟。否则一上来就搞几十个插件你根本分不清哪个按键是哪个插件提供的学习体验容易受挫。7.4 远程开发配置的几点提醒远程开发在 2021 年已经相当流行VS Code 的 Remote-SSH 扩展是很多后端同学的首选本地开着编辑器实际执行代码和编译都在远程服务器上。它的好处是本地不需要装一堆运行时环境电脑配置要求也低。用 Remote-SSH 时有一点我要单独提醒远端最好安装和本地版本一致的 VS Code Server避免插件版本冲突。常见的问题是连接断开会话卡住可以通过右下角状态栏重新加载窗口解决或者直接在远端 .vscode-server 目录里清理残留的进程。如果你连接的是公司内网服务器还要留意网络代理配置有时候连不上并不是 SSH 的问题而是代理环境把连接中断了。这里补充一个远程开发下的实用技巧如果你经常需要编辑/etc/nginx/nginx.conf这类系统级配置文件不要再硬编码远端密码建议在本地配置 SSH 密钥登录并做好 aliasHost my-server HostName 192.0.2.10 User devuser Port 22 IdentityFile ~/.ssh/id_ed25519填好之后直接用ssh my-server就能连上连 VS Code 远程窗口也能识别到这个主机别名。8. 常见问题与排查技巧实录以下问题都来自我这些年实际折腾编辑器时积累的经验汇总成表方便对照。现象可能原因排查/解决办法VS Code 打开项目特别卡插件过多、搜索索引膨胀、内存配置不足禁用不常用的扩展在 settings.json 排除 node_modules/dist考虑按工作区加载扩展Sublime Text 打开文件中文乱码文件编码不是 UTF-8如 GBK安装 ConvertToUTF8 插件或在 File Reopen with Encoding 里手动选择编码Vim 按方向键出现字母 AB CD终端模式/配置问题在 .vimrc 里设置set nocompatible或者确认是否处于正常插入模式不少终端模拟器也需要调整Atom 安装插件后启动缓慢Electron 架构 插件过多减少插件数量尽量用核心功能如果条件允许换 VS CodeJetBrains 系导入工程一直卡在索引本地缓存损坏File Invalidate Caches / Restart也可以调整索引目录范围把不需要索引的目录 Exclude 掉远程开发时 VS Code 提示版本不匹配本地扩展和远端 Server 版本不一致重启远端窗口删除 .vscode-server 相关目录后重新连接Notepad 打开大文件内存爆炸老版本对大文件优化不足升级版本优先用“超大文件查看”模式或换 Sublime Text 处理排查工具问题的共性方法论也很简单先判断“是某个扩展引起的还是主程序引起的”最有效的办法是开一个临时用户配置、禁用全部插件、逐步恢复。我以前修过无数次“编辑器变慢”的问题绝大多数最后都追溯到某个不太起眼的扩展上和转换编辑器本身关系不大。还有一个小细节无论是哪种编辑器养成“定期把配置纳入版本管理”的习惯都会省心很多。VS Code 的 settings.json、Sublime 的 Preferences、Vim 的 .vimrc都可以扔进一个 dotfiles 仓库里。这样你换电脑、换系统、新增同事都能快速复现环境而不是每次在新机器上凭记忆重配一遍。9. 我对选型的一些实在看法写到这里我觉得选编辑器这件事其实有三个层次。第一层是“能不能用”。任何主流编辑器都能完成日常开发区别只在顺不顺手。第二层是“合不合适”。你写 Java 大型工程却用 Notepad 当然也能写但重构、调试体验会非常痛苦你只为改几行配置却开一个 IntelliJ IDEA等待启动的时间成本也划不来。第三层是“用得好不好”。这跟工具本身关系反而没那么大了更取决于你对快捷键、插件、工作流的熟练程度。有一次我去一个团队做技术交流发现好几个人主力编辑器是 Atom但他们的项目规模已经到几千个文件了。我当时好奇问了一句你们是不是遇到过卡顿结果大家齐声说是但没有人觉得这事可以靠换工具解决。后来我只做了一件事帮他们里其中一位装了 VS Code把常用插件配置好跑通了原有项目的调试流程。过了一周这个团队只剩一个人还在用 Atom 了。这里没有任何贬低 Atom 的意思只是要说清楚当工具已经实际阻碍到你日常迭代速度时换工具不是“折腾”而是一种必要的生产力投资。反过来的例子也有。有个运维老哥一直用 Vim 写脚本我劝他试试现代化补全他说自己已经闭着眼改 nginx 配置和写 Python 脚本了Vim 的熟练度早就抵消了“缺少智能提示”带来的影响。我听完觉得很有道理——高手手中的工具已经内化成了能力的一部分。所以在给新人建议时我通常不会直接说“你必须用某款编辑器”而是会问你主要在哪个平台工作写什么语言项目多大需要哪些周边能力你愿意投入多少时间学习工具本身花一个下午把主流编辑器都装上用同一个项目分别跑一遍感受一下启动速度、补全反馈、调试流程和社区文档的完善程度这种亲身体验比看十篇横评文章都管用。至少在 2021 年这个时间点市场上不存在什么“唯一正确的编辑器”只存在“某一类场景下性价比更高的选择”。而选择的关键始终在于你对自己工作流的理解够不够清晰。 
长河君 · 2026/10/20 17:35:18 · 阅读 1.2k 主流代码编辑器横向对比：从轻量到IDE的选型指南
1. 先搞清楚编辑器的江湖格局2021年年中的时候也就是5月份那阵子编辑器圈子的版图其实已经相对稳定了。说“稳定”不是说没竞争而是每个工具在用户心里基本都有了明确标签VS Code 是当红炸子鸡Sublime 是轻量刺客Vim 是终极信仰JetBrains 系是重装主力Atom 是慢慢失宠的前朝遗老Notepad 则是 Windows 老兵的怀旧选择。我当时刚好做了一次比较完整的编辑器选型调研趁着这个机会把这篇文章整理出来把各家主流的代表、适用场景、优缺点以及我实际使用中踩过的坑一并补上。很多人选编辑器时容易陷入两个极端一种是“永远在尝鲜”听说哪款好就换哪款结果一天到晚在迁移配置另一种是“一条道走到黑”明明工具已经严重拖累效率还死活不肯换。我个人的观点一直是——编辑器没有绝对的好只有适不适合你当前的场景。但前提条件是你得先把市面上主流选手的真实底细摸清楚才好做判断。这篇内容主要以 2021 年年中的视角来做横向盘点同时会把一些核心操作思路和配置技巧也放进来方便你拿来做选型参考。就算你眼下不打算换编辑器看看各家设计的理念差异也能反哺你当下工具的使用习惯至少能帮你发现一些平时忽略掉的功能。我给自己定了个框架先按“阵营”把主流编辑器分成四大类——轻量级文本编辑器、全功能 IDE、终端派编辑器、云端/协作型编辑器然后再逐个拆解它们的定位、优势和劣势。这样不会变成一篇纯粹罗列功能说明书的枯燥内容而是真的能理清“我该用哪个”这条主线。2. 轻量级阵营Sublime Text、VS Code、Atom 与 Notepad轻量级编辑器的核心卖点是“快”和“轻”但这里说的“轻”其实分层次。有的是启动快有的是内存占用低有的是安装包小还有的是打开大文件不卡。它们各自优化的方向不太一样选的时候要看你在意哪个维度。2.1 当时最抢眼的 VS Code生态无人能敌2021 年那会儿VS Code 已经连续几年蝉联各种开发者调查的“最受欢迎编辑器”榜首了。它基于 Electron 技术框架打造本质上是运行在 Chromium 内核里的 Web 应用所以界面渲染能力很强而且跨平台一致性好。Windows、macOS、Linux 上长得一模一样团队的协作成本能明显降下来。VS Code 最大的护城河是插件市场。我当时统计了一下Extensions Marketplace 里的插件数量轻松破万无论你写 Python、Go、Rust、前端三件套还是 Kubernetes YAML总能找到对应的语言支持、Lint、格式化、调试配置。而且它的 IntelliSense智能补全是基于语言服务协议LSP做的这让它不只是“花哨记事本”而是无限接近 IDE 的存在。我实际体验中印象比较深的是它的调试器。以前写 Node.js 或者 Python 脚本时我习惯额外开一个调试工具但 VS Code 里面直接按 F5 就能启动调试会话断点、变量监视、调用堆栈全部集成在同一个界面里这确实减少了很多来回切换的时间损耗。还有它的“全局搜索”功能大项目里搜关键词响应速度相当快打开大文件虽然偶尔会有些卡顿但整体仍在可接受范围内。不过Electron 的先天劣势也躲不掉内存和 CPU 占用偏高启动速度比原生应用慢不少。我实际跑过一台 8GB 内存的普通笔记本电脑同时开 VS Code、浏览器、几个终端窗口内存会明显吃紧。如果你电脑配置不高需要在使用前做点减负——比如关闭不需要的扩展、调节搜索排除目录、用工作区而非直接拖文件夹打开。2.2 老牌轻量王者 Sublime Text性能党的心头好Sublime Text 在 2021 年仍然是我心中“性能党首选”之一尤其是它打开超大文件的流畅度很多编辑器都比不了。它用 C 写的底层界面响应非常跟手启动速度几乎是瞬间完成而且它没有 Electron 那套东西占用内存小很多。从 2017 年发布 Sublime Text 3 之后它一直是很多运维、后端工程师手里的常驻工具。Sublime 的核心操作逻辑是“命令面板”CtrlShiftP。这玩意儿用熟了之后你几乎可以不碰鼠标所有功能都可以通过模糊匹配调出来装插件、切语法、改缩进、执行构建全都能在命令面板里完成。它还有一个特色是一次布局里拆多个窗格Grid Layout对于同时对比多个文件非常方便这在处理配置文件比对时帮了我不少忙。但它也有明显短板插件生态和 VS Code 比少了两个量级语言智能补全大多要靠 Package Control 里的社区方案有时候需要手动改配置内置的 Git 集成相当弱通常要配合终端或外部工具还有一个经常被吐槽的点是 License 弹窗——虽然可以无限期试用但时不时会弹一下商业使用还是需要购买授权的。2.3 曾经的明星 Atom慢慢淡出主舞台把 Atom 放在这里更多的是为了做历史参照系。Atom 也是 GitHub 出品的 Electron 编辑器曾经在一段时间内热度非常高很多人是被它的高颜值和高度可定制性吸引入坑的。在 2021 年Atom 还是有一批忠实用户但整体新用户增长已经明显放缓。Atom 的问题主要在于性能。同样是 Electron 底座它在启动速度和响应上比 VS Code 差不少尤其是装了十几个插件之后那种“卡顿感”会真实地影响到日常心情。项目如果稍微大一点Atom 在查找引用、全局搜索这些操作上会有明显延迟。如果说你现在的电脑配置一般又想找一款界面顺眼的编辑器我不太建议选择 Atom——除非你真的大量使用它的“分屏编辑”和“Teletype 协作”功能该功能当时仍在实验阶段。从后来的趋势看GitHub 官方也已经把开发重心转向了 VS CodeAtom 的停更信息其实在社区里早有预兆只是在 2021 年 5 月份这个时间窗口它仍然出现在不少选型文档里。这里我顺带提一句做选型调研时不要只看眼前的下载量还要看看项目维护的活跃度、版本迭代的节奏这才是更长期的判断依据。2.4 Windows 老兵 Notepad小而快但有局限Notepad 在国内的老牌 Windows 用户里认同度很高。它基于 Scintilla 组件开发安装包只有几兆启动快得离谱对电脑配置几乎没有要求。很多运维老哥的习惯是系统里装一个 Notepad改个 hosts、看个日志、写个临时脚本双击就能打开不需要等任何加载动画。但它的缺陷也很明确首先它只支持 Windows如果你偶尔用 macOS 或者 Linux就得找替代品比如 Notepad 的很多功能可以靠 VS Code 替代其次它的智能提示和代码导航能力比现代化编辑器弱很多写大型项目会感觉比较“原始”。另外它的插件机制偏传统虽然有 Plugin Manager但整体丰富度和维护活跃度都一般。2021 年那会儿我也在一些团队环境里见过强制安装 Notepad 的情况理由是“大家都用这个处理文本方便”。但实际上如果团队里有前端或者后端在写代码长期用 Notepad 确实会很痛苦。我的建议是它可以作为 Windows 下的“备用记事本”存在但最好不要作为主力开发工具尤其是当你需要调试、重构、版本管理集成这些能力的时候。综合来看轻量级阵营选型时可以按下面这个思路来判断需求维度推荐选择核心理由跨平台、生态丰富、要调试VS Code插件市场最大语言服务完善极度追求启动速度和低内存Sublime Text原生性能打开大文件快老 Windows 环境、轻量改文本Notepad免安装绿色双击即用追求高颜值与极简风格Atom当时仍可选界面美观但性能是短板3. 全功能 IDE 阵营JetBrains 全家桶与 Eclipse 系列轻量级编辑器解决的是“快速编写与浏览”当你需要应对大型工程、深度重构、复杂调试、性能分析、数据库面板、容器编排等一体化能力时IDE 依然不可替代。这个阵营的典型代表就是 JetBrains 系列以及 Java 世界里根基深厚的 Eclipse 系。3.1 JetBrains 系列语言上下文感知的天花板JetBrains 在 2021 年的产品线已经铺得很广IntelliJ IDEA 主攻 JavaPyCharm 主攻 PythonWebStorm 主攻前端开发GoLand 主攻 Go还有面向数据库的 DataGrip面向多语言协作的 Fleet 也在规划之中。它们共享同一套底层平台IntelliJ Platform所以只要你熟悉了其中一个其他产品上手成本会非常低。JetBrains 系最打动我的是它“深度理解代码”的能力。它不仅仅是基于正则匹配做关键字高亮而是真的会构建项目的语法树和引用关系。比如重命名一个变量时它能自动识别同名的局部变量和外部变量精确地只改该改的地方又比如在 Java 里跳转到接口实现类或者在 Python 里快速定位某个方法的定义——它的索引机制非常高效日常代码导航体验几乎是行云流水。IDE 的代价自然是“重”。以 IntelliJ IDEA 为例首次导入一个大型 Maven 项目时索引构建可能需要几分钟时间期间 CPU 和内存占用非常高。Android Studio 也是基于 IDEA 内核开发的大家应该对这种感觉不陌生——打开工程后就听着风扇转。所以如果你只是写一些小脚本、学习 Demo用 IDE 属于杀鸡用牛刀纯属给自己机器加负担。JetBrains 系还有一个特色是内置了很多“周边能力”数据库工具、HTTP Client、终端模拟器、Docker 插件、远程开发。它们把原本需要切换多个软件做的事尽量在同一个界面里完成。对我个人来说写全栈项目时用一个 WebStorm 或 IntelliJ IDEA 就够了基本不需要额外开数据库管理软件和 API 调试工具。价格方面JetBrains 是收费的按年订阅。当时它也提供针对开源开发者、学生、教育工作者等场景的免费授权如果你是符合条件的用户值得去申请。如果团队预算有限也可以考虑只给后端同事统一采购前端继续用 VS Code各取所长。3.2 EclipseJava 老牌劲旅的挣扎与实用场景Eclipse 在整个 Java 开发史上的地位毋庸置疑。很多老一代 Java 工程师的职业生涯都是从 Eclipse 起步的它的插件体系OSGi 架构曾经极其辉煌。但到了 2021 年Eclipse 在开发者社区的声量明显下降用户增长也主要是传统企业和教学场景带动。Eclipse 的优缺点非常清晰优点是完全开源免费跨平台插件接口开放很多厂商基于它定制自己的 IDE比如早期的 STS、Hibernate Tools 等缺点是架构偏老界面视觉和交互体验比 JetBrains 系粗糙内置的 Maven/Gradle 支持不如 IDEA 顺手Git 集成也比较“直男操作”。如果你是在校学生或者公司有强制要求使用 Eclipse那也没什么问题——它依然能完成 80% 的 Java 开发需求。但如果在选型阶段Java 团队我更推荐直接用 IntelliJ IDEA 社区版或付费版因为日常维护代码的效率差距是能感知到的。Eclipse 最大的生存空间其实在“嵌入式开发”和“特定企业生态”里比如某些厂商提供的 SDK 和插件只做了 Eclipse 版本这时你就没法为了追求好用而随意换工具了。4. 终端派编辑器Vim 与 Emacs 的两种信仰终端派编辑器是一条独特的路线。它们没有界面那些花哨元素一切操作都围绕键盘展开学习曲线陡峭但一旦掌握效率提升非常明显。这个阵营的两位代表 Vim 和 Emacs理念几乎是背道而驰的。4.1 Vim模式化输入练成肌肉记忆Vim 的核心设计是“模式编辑”。它把键盘输入分成普通模式、插入模式、可视模式、命令模式等在不同模式下同一个按键的功能完全不同。第一次接触的人往往感觉莫名其妙——按个 i 才能输入文字按 Esc 又回到普通模式光标移动用 h/j/k/l 而不是方向键。但当你习惯了这种操作逻辑后写代码时“移动光标、选中块、复制粘贴、替换文本”都不需要离开主键盘区手指移动距离大幅减少。Vim 的配置体系也很有特色。用户目录下的 .vimrc 文件可以定义快捷键、安装插件通过 Vundle、vim-plug 等插件管理器、定制主题。2021 年时Neovim 已经成为 Vim 社区的一个重要分支它重构了内部架构让异步执行和内置终端支持变得更好很多人也因此重新关注起终端编辑。我早期用 Vim 时也走过弯路一上来就想配出“IDE 一样的体验”装了几十个插件结果维护成本比写代码还高。后来我认清了一个道理——Vim 最适合的场景是“快速编辑服务器配置文件、在远程终端里改代码、写 Git commit message、处理临时文本”而复杂项目的主力开发可以把 Vim 的按键绑定作为插件装到 VS Code 或 IDE 里而不是真的用纯 Vim 去完成全部工作。这个思路很实用在 VS Code 里装 Vim 插件你既能享受到现代化编辑器的补全、调试、代码导航能力又能用 Vim 的按键习惯快速操作两全其美。许多 JetBrains 系 IDE 也有对应的 Vim 模拟插件IdeaVim用法类似。愿意付出学习成本的人这套组合的收益是非常可观的。4.2 Emacs可编程编辑器一切皆可定制Emacs 的历史比 Vim 还要久远它的核心理念是“Everything is a buffer”界面上的任何内容本质上都是文本缓冲区而且它内嵌了一个 Lisp 解释器理论上你可以用 Lisp 语言把编辑器改造成任何形态。这种高度的可扩展性让它在一些技术极客和学术圈子里拥有稳固的社群。但 Emacs 的问题也很明显默认配置上手难度极高新手连退出都搞不清快捷键Ctrlx Ctrlc 是退出更不用说扩展包的安装与加载机制。Evil 模式可以让你用 Vim 的按键习惯操作 Emacs算是融合了两个世界但整体学习曲线依然很陡。如果你对“用编辑器写程序来控制编辑器”这件事本身不感兴趣那我不太建议把 Emacs 作为日常主力。它的价值更多体现在方法论层面的启发——编辑器不只是一个输入工具它甚至可以说是一个操作系统的前端壳。对于想深入理解编辑器设计哲学的人来说Emacs 是一本很值得翻阅的教材。5. 云上和协作编辑器的新边疆2021 年值得关注的一个方向是云编辑器和对协作能力的重视。过去我们习惯“本地装环境代码在本地跑”但云开发的出现改变了这个模式。5.1 在线编辑器与应用场景GitHub 的 Codespaces、Gitpod 这类云端开发环境再加上一些轻量级的基于 Web 的 IDE如 StackBlitz、CodeSandbox让“浏览器里写代码”变得可行。它们的核心思路是云端提供统一的开发环境本地只负责浏览器渲染与交互配置和环境依赖都可以在云端容器里预先构建。这种方式在大型团队里尤其有吸引力——新成员入职后不需要折腾一整天“本地环境搭建”打开浏览器就能有可用的开发环境。我当时尝试过用 Codespaces 跑一个前后端分离的项目初始化体验已经相当顺畅仓库里有 Dockerfile 和 devcontainer 配置的话云端环境会自动拉起数据库、缓存、依赖包和本地效果一致。不过网络条件对体验影响比较大在国内访问这类服务的稳定性可能会有波动这部分我当时没有深入测具体以你自己实际网络环境为准。如果你更多是写前端 Demo、临时验证一段代码CodeSandbox 这类轻量网页编辑器也值得熟悉。它们内置了常用的框架模板改动可以实时预览还能自动生成分享链接。这种“零配置、即开即用”的体验在某些教学、分享场景下比本地编辑器便捷很多。5.2 多人在线协作的协作体验过去“多人同时改一个文件”在传统编辑器里几乎不敢想象一般只能靠版本管理工具Git来解决冲突。现在部分在线编辑器和 VS Code 的 Live Share 扩展可以实现“结对编程”式协作不同的人同时查看同一个文件一个人写代码另一个人光标实时跟随甚至共享调试会话和终端。这对远程办公、技术辅导、代码评审都有实实在在的帮助。我在实际团队协作中用过 Live Share体验是“秒级的同步”几乎没有明显延迟。它的定位不是替代 Git而是在你“需要即时讨论一段代码”时省去反复推送分支、拉取代码、打开 Diff 的环节。这个工具在 2021 年已经有较成熟的表现如果你团队里有远程办公的需求可以纳入考虑范围。6. 真实项目里的选型组合与配置实战前面说了那么多对比关键是落地。这里我用几个真实工作场景来演示“怎么选编辑器组合”并附上一些可复现的配置实操。6.1 后端微服务团队怎么配团队如果主要是 Java 生态我建议主力 IDE 用 IntelliJ IDEA。在 IDEA 里我通常会做三个关键调整把内存堆设置调大在 Help Change Memory Settings 里根据机器配置把堆内存从默认的 2048MB 适当调高。我常在 16GB 内存的机器上调到 4096MB大项目索引速度会有明显改善。开启“按需导入”和“自动导入”功能减少手动管理 import 的琐碎感。配置统一代码风格文件.editorconfig 或 IDE 的 Code Style Scheme保证团队提交代码格式一致减少没必要的格式冲突。如果团队同时要处理一些轻量级脚本、运维配置可以搭配 VS Code 作为辅助工具专门用来快速改 YAML、JSON、Shell。这样疾如风的工具做轻活重火力的 IDE 做重活各司其职。6.2 前端全栈开发怎么选前端人的主阵地其实 VS Code 就很能打内置的调试器可以直接调试浏览器里的代码还有 ESLint、Prettier、Tailwind 提示等插件。加上“代码片段”功能可以把高频模板比如 React 组件结构一键补全效率提升很直接。如果你的前端项目还涉及 Node.js 后端或者你需要在同一个工具里同时看数据库、调接口、跑脚本用 WebStorm 会更爽。它把 HTTP Client类似 Postman、数据库工具、终端全塞在编辑器里可以少装很多独立软件。我个人的常用组合是主力 WebStorm 写工程收尾做快速演示或临时改文件时开 VS Code。需要强调的是梳理好“主力”与“辅助”比不断切换工具更重要。因为每款编辑器都有自己的缓存、索引机制和插件体系频繁切换往往会让你的注意力碎片化。上面这套思路可以参考这首打油诗我朋友编的VSC 补全真方便Sublime 打开大文件JetBrains 智能不一般Vim 远程改配置还算稳。虽然不完全严谨但对于快速向新同事解释选型差异还挺好用的。7. 我的配置片段与日常避坑心得有些配置细节对新手来说不容易找到这里我放几个自己正在用的片段并说明为什么这么配。7.1 VS Code 的 settings.json 精简优化我个人偏好关闭“编辑器动画”和“像素对齐”之类对性能影响较大但对实际编码帮助很小的特效并在搜索时排除 node_modules、dist 这类明显不需要搜的目录{ editor.fontSize: 15, editor.formatOnSave: true, editor.minimap.enabled: false, files.exclude: { **/node_modules: true, **/dist: true }, search.exclude: { **/node_modules: true, **/dist: true }, editor.renderWhitespace: selection, git.autofetch: true }这几个配置的核心思路就是减少视觉干扰、去掉无效搜索、保存时自动格式化、让 Git 状态自动保持最新。实测下来对大项目的日常体验提升很明显。7.2 Sublime Text 打开超大日志的优化如果你经常需要查看几百 MB 甚至上 GB 的日志文件Sublime Text 是最顺手的工具之一。用之前可以在设置里加一行highlight_line: false, word_wrap: false这样能减少渲染负担在超大文件里滚动时能明显感觉到更跟手。如果在打开文件后还是卡可以进 Preferences Settings 关闭自动缩进检测或者改用二进制/纯文本模式查看。7.3 Vim 小白快速配置如果你刚开始接触 Vim我建议不要急着上插件全家桶先把最基本的 .vimrc 配置写好set number set relativenumber set tabstop4 set shiftwidth4 set expandtab syntax on filetype plugin indent on set clipboardunnamedplus这段配置解决的问题很直接显示行号、相对行号方便跳转、统一缩进为空格、打开语法高亮、共享系统剪贴板。先把这些基础体验稳下来再去玩插件不迟。否则一上来就搞几十个插件你根本分不清哪个按键是哪个插件提供的学习体验容易受挫。7.4 远程开发配置的几点提醒远程开发在 2021 年已经相当流行VS Code 的 Remote-SSH 扩展是很多后端同学的首选本地开着编辑器实际执行代码和编译都在远程服务器上。它的好处是本地不需要装一堆运行时环境电脑配置要求也低。用 Remote-SSH 时有一点我要单独提醒远端最好安装和本地版本一致的 VS Code Server避免插件版本冲突。常见的问题是连接断开会话卡住可以通过右下角状态栏重新加载窗口解决或者直接在远端 .vscode-server 目录里清理残留的进程。如果你连接的是公司内网服务器还要留意网络代理配置有时候连不上并不是 SSH 的问题而是代理环境把连接中断了。这里补充一个远程开发下的实用技巧如果你经常需要编辑/etc/nginx/nginx.conf这类系统级配置文件不要再硬编码远端密码建议在本地配置 SSH 密钥登录并做好 aliasHost my-server HostName 192.0.2.10 User devuser Port 22 IdentityFile ~/.ssh/id_ed25519填好之后直接用ssh my-server就能连上连 VS Code 远程窗口也能识别到这个主机别名。8. 常见问题与排查技巧实录以下问题都来自我这些年实际折腾编辑器时积累的经验汇总成表方便对照。现象可能原因排查/解决办法VS Code 打开项目特别卡插件过多、搜索索引膨胀、内存配置不足禁用不常用的扩展在 settings.json 排除 node_modules/dist考虑按工作区加载扩展Sublime Text 打开文件中文乱码文件编码不是 UTF-8如 GBK安装 ConvertToUTF8 插件或在 File Reopen with Encoding 里手动选择编码Vim 按方向键出现字母 AB CD终端模式/配置问题在 .vimrc 里设置set nocompatible或者确认是否处于正常插入模式不少终端模拟器也需要调整Atom 安装插件后启动缓慢Electron 架构 插件过多减少插件数量尽量用核心功能如果条件允许换 VS CodeJetBrains 系导入工程一直卡在索引本地缓存损坏File Invalidate Caches / Restart也可以调整索引目录范围把不需要索引的目录 Exclude 掉远程开发时 VS Code 提示版本不匹配本地扩展和远端 Server 版本不一致重启远端窗口删除 .vscode-server 相关目录后重新连接Notepad 打开大文件内存爆炸老版本对大文件优化不足升级版本优先用“超大文件查看”模式或换 Sublime Text 处理排查工具问题的共性方法论也很简单先判断“是某个扩展引起的还是主程序引起的”最有效的办法是开一个临时用户配置、禁用全部插件、逐步恢复。我以前修过无数次“编辑器变慢”的问题绝大多数最后都追溯到某个不太起眼的扩展上和转换编辑器本身关系不大。还有一个小细节无论是哪种编辑器养成“定期把配置纳入版本管理”的习惯都会省心很多。VS Code 的 settings.json、Sublime 的 Preferences、Vim 的 .vimrc都可以扔进一个 dotfiles 仓库里。这样你换电脑、换系统、新增同事都能快速复现环境而不是每次在新机器上凭记忆重配一遍。9. 我对选型的一些实在看法写到这里我觉得选编辑器这件事其实有三个层次。第一层是“能不能用”。任何主流编辑器都能完成日常开发区别只在顺不顺手。第二层是“合不合适”。你写 Java 大型工程却用 Notepad 当然也能写但重构、调试体验会非常痛苦你只为改几行配置却开一个 IntelliJ IDEA等待启动的时间成本也划不来。第三层是“用得好不好”。这跟工具本身关系反而没那么大了更取决于你对快捷键、插件、工作流的熟练程度。有一次我去一个团队做技术交流发现好几个人主力编辑器是 Atom但他们的项目规模已经到几千个文件了。我当时好奇问了一句你们是不是遇到过卡顿结果大家齐声说是但没有人觉得这事可以靠换工具解决。后来我只做了一件事帮他们里其中一位装了 VS Code把常用插件配置好跑通了原有项目的调试流程。过了一周这个团队只剩一个人还在用 Atom 了。这里没有任何贬低 Atom 的意思只是要说清楚当工具已经实际阻碍到你日常迭代速度时换工具不是“折腾”而是一种必要的生产力投资。反过来的例子也有。有个运维老哥一直用 Vim 写脚本我劝他试试现代化补全他说自己已经闭着眼改 nginx 配置和写 Python 脚本了Vim 的熟练度早就抵消了“缺少智能提示”带来的影响。我听完觉得很有道理——高手手中的工具已经内化成了能力的一部分。所以在给新人建议时我通常不会直接说“你必须用某款编辑器”而是会问你主要在哪个平台工作写什么语言项目多大需要哪些周边能力你愿意投入多少时间学习工具本身花一个下午把主流编辑器都装上用同一个项目分别跑一遍感受一下启动速度、补全反馈、调试流程和社区文档的完善程度这种亲身体验比看十篇横评文章都管用。至少在 2021 年这个时间点市场上不存在什么“唯一正确的编辑器”只存在“某一类场景下性价比更高的选择”。而选择的关键始终在于你对自己工作流的理解够不够清晰。