从Neovim回到Vim：2025年，为什么跨环境可用性比编辑器功能更关键

我得先承认一件事：从去年开始，我把主力环境从用了好几年的 Neovim 切回了 Vim，而且不是一次冲动的决定，是反复横跳之后的选择。现在每次发相关帖子，评论区总有人问“2025 年了，为什么还有人用 Vim 不用 Neovim”。我把相关的讨论帖和热搜词翻了一圈，发现这个问题背后其实藏着很有意思的东西——它不是简单的“谁比谁强”的技术对比，而是一群用户的工作方式、使用场景和迁移成本在起作用。

我最早是坚定的 Neovim 尝鲜派。2015 年它刚 fork 出来那会儿，我几乎第一时间就装了，原生的异步任务、内嵌终端、remote plugin 架构，每一个都长在我的需求点上。后来 0.5 版本内置 LSP 支持，我又跟着把配置从 vimrc 折腾成 init.lua，折腾得不亦乐乎。但折腾了几年，最后我还是回到了 Vim。这中间的每一次切换都有具体原因，不是“情怀”两个字能解释的。

如果你现在也在这两个编辑器之间摇摆，或者你身边有人守着 Vim 不肯走，你却不理解为什么，那这篇文章应该能帮你理清思路。我会从真实的使用体验讲起，少谈“主义”，多谈“场景”。

1. 我为什么从 Neovim 用回了 Vim

1.1 从尝鲜到主力：Neovim 确实带来了好东西

先给 Neovim 说句公道话。我在 2016 到 2019 年期间，几乎把 Neovim 当主力用了三年。那个阶段的体验提升非常明显：异步 job 让插件不再因为跑个 grep 就把整个编辑器卡住；内置终端让我在一个窗口里就能跑测试；后来 0.5 的 LSP 客户端 + Treesitter 直接让 Vim 系编辑器跟现代 IDE 的差距缩小了一大截。当时我在本地写 Go 和 Python，补全、跳转、悬停文档都流畅得让人感动。

所以每次看到有人吐槽“Vim 已经落后于时代”，我都会想起那段用 Neovim 的快乐时光，它确实推动了这个生态往前走，Vim 8.0 后来补上的异步、job、lambda 等特性，某种程度上也是被 Neovim 逼出来的。作为用户，我们应该感谢这种竞争。

1.2 真正劝退我的不是功能，是“每个版本都在改玩法”

但问题也随之而来。Neovim 的发展速度太快了，快到配置体系的“保质期”越来越短。我从 vimscript 迁到 Lua，从 Lua 里一堆 vim.api.nvim_set_keymap 的老写法，再迁到后面更简洁的 vim.keymap.set，中间改配置占了大量时间。每次版本升级，未必是功能出问题，而是社区推荐的最佳实践变了，你看着自己的配置总觉得“不现代化”，于是又想去改。

相比之下，Vim 的配置写了十年还能用，这是一种非常扎实的稳定感。我得承认，对一个每天要把大量时间花在写代码而不是写编辑器配置上的人来说，这种稳定感是最高优先级。Neovim 的很多插件会要求你安装最新版，不更新就报错；而 Vim 的生态里，老配置、老插件继续跑的情况非常多。

1.3 一次偶然的服务器经历，让我彻底下定了决心

真正让我彻底切回 Vim 的契机，是一次在客户内网环境里的排障。那台机器没有外网，系统比较老，预装的是 Vim 7.4。我当时习惯性地想开 Neovim，结果发现机器上根本没有，也装不了。最后我只能用系统自带的 Vim，敲了几条命令，完成了日志分析和配置文件修改。那次经历让我意识到一个被很多人忽略的事实：Vim 的“可用边界”比 Neovim 宽太多太多，我不希望自己的核心编辑能力绑定在一个需要预装、需要生态支持、需要特定版本才能跑的工具上。

从那天起，我开始认真调整自己的配置，让主力环境回归 Vim，并且要求自己做到：在任何一台机器上，只要有一个 Vim，我就能维持八成以上的工作效率。

2. “开机即有”才是 Vim 最深的护城河

2.1 Vim 几乎无处不在，但 Neovim 不是

很多讨论默认了一个前提：“环境都是你自己的开发机，想装什么装什么。”这个前提在真实世界里经常不成立。

你登录一台新开的云服务器，sudo apt install vim 或者直接在系统镜像里可能已经带了 vim-tiny；你进入一个正在排障的 Docker 容器，里面可能连包管理器都没有，但 vi 一定存在；你通过跳板机连到客户的隔离网络，为了安全策略你根本不能往里传二进制文件，这时候能在终端里陪你打仗的，几乎只有 vi/Vim。

这种“开机即有”的特征是一种极强的护城河。Neovim 再优秀，它需要安装、需要额外依赖、需要你有权限去部署，这台机器你没有 sudo 时可能就彻底没戏。而 Vim 呢，它是大多数 Unix/Linux 系系统的基本组成部分，是系统的“默认工具”之一，就像 ls、grep 一样，不需要你额外申请。

2.2 最低摩擦原则：解决“此刻只想改个文件”的需求

有人会说：“既然要做主力开发，那肯定要用更好的工具，一次性装好。”但现实中很多使用场景根本不是开发，只是“此刻要快速改文件”。

举个例子，生产环境上一个服务挂了，你 SSH 上去看日志，发现某个配置文件里有个参数要调。你希望的路径是：一秒打开文件→移动光标到对应行→修改→保存退出。这时候任何需要等待插件加载、LSP 启动、或者还需要安装配置的编辑器，都显得又重又慢。Vim 哪怕是 vim-tiny，没有语法高亮、没有插件，也能在 0.1 秒内完成这个任务。

这里有一个容易混淆的点：Neovim 的启动速度其实已经不慢了，但问题根本不在于启动速度，而在于“这台机器上有没有 Neovim”。如果一台机器上根本没有，启动速度就是无限大。

2.3 服务器、CI、容器场景下的天然优势

我自己维护过不少 CI 流水线。在 CI 镜像里，为了减少构建时间和镜像体积，很多基础镜像非常精简，不会预装 Neovim，但大概率有 Vi。你在 Dockerfile 里想改个文件、想在执行脚本里做点文本替换，vim -es 甚至 vi 都能直接上。

这个优势还延伸到一种很常见的场景：运维事故排查。系统都起不来了，你能用的只有单用户模式的控制台，那里面可没有几十 MB 的编辑器，Vim 这种体积小、依赖少的工具才是救命稻草。Neovim 虽然主程序也不算很大，但它依赖的 libuv、消息解析这些组件，在极端环境下未必都能满足。

3. 能远程用十年的配置，比短期的炫酷更重要

3.1 插件生态的“单向兼容”问题，被大多数人忽略了

讨论 Vim 和 Neovim 时，人们经常说“Neovim 可以兼容大部分 Vim 插件”。这个说法没错，但它只说明了一个方向。反过来的情况是：Neovim 下的现代插件，尤其是那些基于 Lua、用了 Treesitter API、依赖内置 LSP 生态的插件，往往无法在 Vim 里运行。

如果你是一个长期维护自己编辑器配置的人，这个“单向兼容”会造成一个很实际的决策差异：选择 Vim，意味着你的配置库能覆盖的平台范围更广；选择 Neovim，则等于主动走进一个只向前看的生态。两种选择没有绝对对错，但如果你经常需要跨机器、跨环境工作，Vim 的兼容边界会更让你安心。

我自己的插件数量不多，但每个都是精挑细选的。我试着把它们放在 Vim 8.2 和 Neovim 0.9 下同时跑，发现真正能在两边都稳定运行不报错的，反而多是那些“很老”的纯 Vimscript 插件。而这类插件恰恰是很多 NeoVim 用户不屑于用的。

3.2 “时间胶囊”问题：老服务器上的 Vim 版本会卡住你

另一个真实痛点，是生产环境中 Vim 的版本会“卡住”。很多公司的内部系统基于老发行版，自带的 Vim 还停留在 7.4 甚至更老。这个版本没有异步任务、没有 +job、没有内置终端，很多现代插件跑不起来。

遇到这种环境，Neovim 的思路是“让你能在老系统上安装新版本”，听起来不错，但实际你面对的可能是没有外网、没有编译器、没有权限的三重限制。Vim 用户的选择往往很朴实：把配置降低到能在这台老机器上运行的水平，用一套“复古但可靠”的配置来应对。

这种“为了一个环境去降低整个工具链复杂度”的做法，在 Neovim 社区不太会被提及。但很多坚持 Vim 的老手，其实都是这么干的。他们的 vimrc 里不会有花哨的自动补全、不会有浮空窗口，但会有一堆针对老版本的 if has('patch-8.x.xxxx') 兼容性判断。

3.3 我的跨环境兼容策略供你参考

如果你想兼顾新机器的体验和老机器的最低可用性，可以参考我的做法：

• 基础配置永不使用 Lua，只用纯 Vimscript 和 Vim 内置命令。
• 写清楚 if has('gui_running')、if exists('*luaeval') 这类条件分支，让配置在不同功能级别下自动降级。
• 对需要外部依赖的功能（比如 LSP），用普通命令行的方式包一层，而不是直接绑定某个插件。
• 插件尽量选择纯脚本实现、不依赖 pynvim、node 等运行时的类型。

这套配置拿到老服务器上，语法高亮可能没效果，但这只是视觉层面的损失。当你要在那台机器上快速处理问题时，所有核心按键、宏、正则、跳转、窗口操作都正常工作。

3.4 新旧环境下的插件兼容性差异一览

这种差异带来的感受很直接：Vim 是一条“老路但路面长期不变”的高速，Neovim 是一条“有更多新出口但时不时封路重铺”的新区。每天通勤的人，往往更关心路面是否一直能走，而不是有多少条新出口。

4. 性能的真相：多数人用的是“编辑器的可用性”，不是“编辑器的快慢”

4.1 启动速度对比可能没有参考价值

评测里常用“启动时间”来对比 Vim 和 Neovim。我实测过，在不加载插件的情况下，两者启动都快到难以察觉，基本上都是几十毫秒级别。加载一堆插件之后，Neovim 凭借 Lua 的预加载有时会占一点优势，但这种差距在远程服务器上会被网络延迟盖过，甚至不会有感知。

真正影响你日常体感的，往往不是启动速度，而是另外几件事：打开大文件是否卡顿、滚屏是否掉帧、Vim 进程在后台长期挂着内存涨不涨、插件在每次按键后会不会阻塞事件循环。在这些方面，双方各有胜负，但 Vim 的表现非常稳。

4.2 处理超大文件和大日志时的体感对比

我处理过大几 GB 的日志文件。这个场景下，Vim 打开文件时会禁用部分高亮、折行、语法等重功能来保证流畅，这已经形成了一套成熟的降级机制。Neovim 如果默认开着 Treesitter，打开超大文件反而可能要手动关闭相关插件，否则渲染开销会让你明显感到卡顿。

当然，Neovim 里也有配置可以关闭插件，很多想得周到的用户会做自动探测。但这里暴露的是设计哲学差异：Vim 的核心思路是“即便功能砍掉不少，也要保证基本编辑流畅”；Neovim 的核心思路则更偏向“平台能力强，你按需自己调”。前者的默认行为对处理服务器日志、核心转储等临时任务更友好。

4.3 长会话内存占用：在开发机上不明显，在跳板机上很明显

还有一个场景我很少看到有人提：长时间挂着编辑会话。我习惯在终端里开多个标签页，常常一个星期都不关。在开发机上，16GB、32GB 内存随便挥霍，Vim 和 Neovim 的差别看不出来；但在一些低配的跳板机、CI 执行器上，你能分到的内存可能只有 512MB，这时候一个常驻的编辑器多占 50MB 都有压力。

我做过一个不严谨的对比：同样打开一个中等规模代码仓库，空跑在后台，Vim 的 RSS 大概在 20~40MB，Neovim 加上默认加载的 Lua 运行时和一些内置模块，经常高出 20%~40%。这个差别对日常开发来说无伤大雅，但它在低配环境里是实打实的可用性差异。很多 Vim 老用户不是买不起新机器，而是他们要维护的服务器可能真的很老。

4.4 一些“盲优化”提示

如果你决定继续用 Vim，有几件事能优化性能，让你感知更明显：

• 大文件下用 :set eventignore+=Syntax 或手动关闭语法高亮。
• 用 set lazyredraw 减少宏录制时的重绘。
• 尽量使用 gg、G、<C-f> 这类跳转方式，而不是频繁长按方向键滚屏。
• 对于日志文件，别用默认编辑器打开后直接拖到底部，很多场景 tail + grep 结合 Vim 会更高效。

这些技巧在 Neovim 下同样适用。但如果你问“哪个更省心”，我的回答是 Vim，因为它往往不会主动给你加载那些“默认觉得你需要”的重功能。

5. 很多时候，人们要的只是“一个编辑器”，不是“一个平台”

5.1 Neovim 已经变成了“平台级”工具，而这并不适合所有人

Neovim 这些年越来越像“一个可以终身折腾的平台”。内置 LSP、Treesitter、大量基于 Lua 的扩展机制，让它可以被塑造成接近 IDE 的开发环境。有人统计过，一个重度 Neovim 用户的配置可能超过几千行，插件几十个，甚至搞出复杂的 on_attach 逻辑来适配不同语言的 LSP server。

这种能力上限确实高，但它也反过来要求使用者投入大量时间维护。对很多只想打开文件写几段代码、用宏处理几组文本、或者改改配置文件的人来说，这种“平台化”的复杂度不是价值，而是负担。

我见过太多新人，听说 Neovim 更现代，于是去搜寻一堆配置模板，最后光折腾插件就花了一个星期。而同样一个新人，如果从 Vim 开始，可能一个小时就能上手基础编辑，一星期后已经能比较流畅地改文件了。

5.2 编辑器外的世界已经足够复杂，很多人不想再维护编辑器本身

这个问题如果往深了说，其实是工作流的哲学分歧。现代开发的复杂度已经很高了：要理解业务代码、要设计系统、要处理部署、要排查网络。对一部分人来说，编辑器最好是一个确定性很强的工具，打开就用，行为稳定，没有惊喜也没有惊吓。

Vim 的身份就是一个纯粹的编辑器：不主动内置语言服务、不强行搞语法树、不在你发布代码或调试时插一脚。它把这些工作交给了外部工具链，配合终端里的编译器、调试器、测试命令，组成一套非常成熟的 Unix 风格工作流。Neovim 则在走向“编辑器 + IDE 运行时”的整合体，这种整合对喜欢一站式体验的人很好，但对坚持“单一职责原则”的人来说，是过度工程化。

其实这就是“分别用 vim 和 xcode”这类问题背后真正要问的东西：你是要一个与外部工具链松耦合的编辑器，还是要一个把所有功能集成在一起的开发环境？这两种偏好没有高下，但显然，Vim 的用户群体普遍属于前者。

5.3 游戏化的入门教程，反而巩固了 Vim 的独有文化

有意思的是，每当人们讨论“为什么不换编辑器”，都会有人提到 vim 大冒险这类游戏化的学习工具。很多新人通过玩游戏学会了 hjkl、学会了各种 operator 组合，这个入门过程会培养出一种别的地方得不到的“键位肌肉记忆”。

这部分用户的习惯一旦形成，就很难再谈“换编辑器”，因为核心编辑体验是跟着人走的。即使 Neovim 几乎完整继承了键位和模式编辑，但在老用户心里，“vi 的编辑模型”本身就是工具价值的主体，至于底层是 C 还是 Lua，是不是异步，影响反而很小。

这也解释了一个现象：很多人换到 Neovim 的理由是“开发体验更好”，而坚持 Vim 的人通常会回答一句“我需要的编辑体验，Vim 一直都有”。两者不在同一个需求维度上，谁都说服不了谁。

6. 给还在纠结的人：我的选择逻辑和维护方案

6.1 三种典型人群选择 Vim vs Neovim 的决策参考

我整理过一张简单的决策指引，也许能帮还在纠结的人做判断。

这里说的“更推荐”只代表我见过的大量案例里的共同倾向，不代表没有例外。你有任何一条特殊理由，都值得打破推荐。

6.2 我目前的折中维护方案：一份配置应对两个环境

我自己目前的做法是“双轨制”的基础配置：日常远程和简单编辑用系统自带的 Vim，本地需要更丰富体验的开发机上，我可以同时跑 Vim 和 Neovim，但核心配置共用一份 base.vim，再针对 Neovim 写一个极薄的 init.lua 加载它。

大概思路是这样：

• base.vim 里只放最通用的设置、键位、插件管理器核心配置，不依赖 Lua，不用 Neovim 专属 API。
• ~/.vimrc 里直接 source 这份 base.vim，然后按需加 Vim 特有的设置。
• ~/.config/nvim/init.lua 里通过 vim.cmd.source 加载同一份 base.vim，再用 Lua 扩展一点 Neovim 增强功能。

这样两边的主力体验一致，我不会在切换时产生键位混乱。同时我的核心能力锚定在 Vim 的命令行编辑模型上，不管底层是哪一个，我都能干活。

如果你要照抄这个方案，有一个小提醒：尽量别在公共 base.vim 里写死插件路径或外部二进制路径。你最好用 exists('g:loaded_xxx') 或版本判断做保护，免得在某个环境里加载不存在的插件时报错。

6.3 我建议你也定期做一次“裸奔训练”

我很推荐一种验证方式：每个月抽一天，故意不加载任何配置，在纯 Vim 环境下完成一次真实的编辑或排障任务。命令是 vim -u NONE，甚至直接打开系统自带的 vi。这样做能让你感知到，哪些“效率”其实来自插件，哪些真正属于你大脑里的编辑能力。

我做过几次之后就明显感觉到，自己已经不太依赖补全和文件树了。有时纯命令行的编辑反而更接近“心流”，因为你没有弹窗、没有高亮、没有无谓的信息流。对 Vim 老用户来说，这种“能随时退到最简环境”的底气和掌控感，可能是比任何功能都更有吸引力的东西。

回到标题的问题：人们为什么还在用 Vim 而不是 Neovim？在我看来，这不是一个关于技术先进性的问题，而是一个关于选择边界的问题。有人看重单机开发体验的极致，有人看重跨环境的普适可用；有人愿意把编辑器打造成平台，有人只想让编辑器安静地做它自己的事。

我自己走了很长的路才发现，最舒服的状态不是“找到最好的编辑器”，而是“在任何一台机器上都能顺畅地编辑”。Vim 恰恰给我这种自由。Neovim 很好，但它代表的那种需要持续投入、持续追赶的使用方式，已经不是我现在想要的生活了。如果你也在两者之间犹豫，不妨先想清楚自己属于哪一种需求，再做决定。