从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 不是

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

你登录