转Reddit技术博主的帖子：我的 Neovim 插件哲学
作为一名资深的系统程序员 ，我日常工作会处理大型的单体代码仓库（monorepos） ，项目文件数超过 4 万 ，代码行数超过 400 万 。在这样的环境下，我对开发工具的要求是：极简、高效、启动快。
我的插件哲学是：尽可能少用插件，尽可能少用花哨功能，只保留工作必需的核心特性。
我对 Mini.nvim （或者任何类似的 Neovim 功能标准库）的理念非常认同。它提供了一套几乎是所有 Neovim 用户都需要的基础功能，而这些功能可能还不适合直接集成到 Neovim 核心中。我认为，一个现代化的编辑器不应该要求用户"从零开始"，四处搜寻并盲目安装 10 到 20 个主流插件才能获得一套完整的功能。
这次尝试，我就是想看看能否用 Mini.nvim 替换掉我配置中那些"常规"的插件，实现一次彻底的配置"瘦身" 。
注意： 我目前使用 Neovim Nightly 版本，并继续使用 pack 进行插件管理（不切换到 Lazy 或 Packer 等），这个依赖管理方式不会改变。
插件对决：Mini.nvim vs. 常规插件
接下来，我将按照功能模块，逐一分享我使用 Mini 系列插件替换主流插件的体验和决定。
1. 文件浏览器 (File Explorer)
| 常规插件 | Mini.nvim 替代品 | 切换结果 |
|---|---|---|
| Oil.nvim | Mini.files | 未切换 |
体验与分析：
Mini.files 倾向于使用浮动窗口 (popup window) 来显示文件列表，这是我遇到的第一个主要"痛点"。在我看来，文件浏览这种功能，在普通缓冲区 (normal buffer) 中展示才更合理，或者至少应该提供在缓冲区中打开的选项。
浮动窗口的弊端： 使用浮动窗口意味着：预览窗口会不断地向右侧移动和重新调整大小，眼睛需要频繁横跨屏幕；打开文件需要按两次键（l 和 q），而不是使用更直观的 同时完成打开文件和关闭界面的操作。
我的结论： 虽然浮动窗口在需要同时打开多个分屏的特定场景下有用，但对我来说，全缓冲区的视图才是更主流、更高效的工作方式。因此，我保留了 Oil.nvim。
2. 会话管理 (Session Management)
| 常规配置 | Mini.nvim 替代品 | 切换结果 |
|---|---|---|
| 自定义 Vimscript/Lua | Mini.session | 切换成功 |
体验与分析：
我过去不得不自己编写一些 Vimscript/Lua 来实现本地会话管理。Mini.session 成功地让我抛弃了这些自定义代码，这是一个重大的改进，切换成功。
3. 启动页 (Startup Screen)
| 常规插件 | Mini.nvim 替代品 | 切换结果 |
|---|---|---|
| vim-startify | Mini.starter | 切换成功 |
体验与分析：
Mini.starter 使用 Lua 编写，更加极简 ，完全能够满足启动页的需求，我非常喜欢，切换成功。
4. 模糊查找器 (Fuzzy Finder)
| 常规插件 | Mini.nvim 替代品 | 切换结果 |
|---|---|---|
| fzf-lua | Mini.picker | 未切换 |
体验与分析：
Mini.picker 仍然采用了浮动窗口。虽然 Mini.files 提供了侧边预览（但有上述问题），但 Mini.picker 却没有侧边栏的文件预览（虽然可以通过 深入预览）。
一致性问题： 在文件列表中选择文件时需要侧边预览，但在模糊查找文件名时却不需要？我感到这种设计不一致。
界面空间浪费： 当我查找文件时，我的主要目标是看到查找器 和文件预览 ，不需要看到后面已经打开的六个窗口。浮动窗口在模糊查找时浪费了大量的屏幕空间。
性能： 在处理某些任务时，我感觉 Mini.picker 略慢于 fzf-lua。
尽管我很想为了减少依赖而切换，但考虑到体验和性能，我最终没有切换。
5. 词语高亮 (Word Highlighting)
| 常规插件 | Mini.nvim 替代品 | 切换结果 |
|---|---|---|
| illuminate.nvim | Mini.cursorword | 切换成功 |
体验与分析：
功能完全一致，即插即用 ，轻松获胜，切换成功。
6. 键位提示 (Keymap Hint)
| 常规插件 | Mini.nvim 替代品 | 切换结果 |
|---|---|---|
| which-key.nvim | Mini.clue | 切换成功 |
体验与分析：
Mini.clue 提供了很多默认的可选键位映射 ，并且设计上极简 。这是一个小小的浮动窗口 真正发光发热的领域，因此我切换成功。
7. Git 核心操作 (Git Wrapper)
| 常规插件 | Mini.nvim 替代品 | 切换结果 |
|---|---|---|
| fugitive.vim | Mini.git | 未切换 |
体验与分析：
我不理解 Mini.git 文档中提出的哲学观点：Git 封装器应该只关注当前缓冲区的"工作集" 。
逻辑矛盾： Git 是在仓库/索引级别工作的。为什么我们不应该关心那些可能被暂存（staged）但未在当前缓冲区打开的文件？如果我在当前缓冲区添加了代码块（hunks），我肯定想查看整个 Git 索引状态。
工作流割裂： 作者似乎建议使用 lazygit 来查看索引，但这又带来了工作流的割裂。如果 fugitive 的 :G 视图已经能让我们在 Neovim 中完成大部分简单的 Git 流程，为什么还要拆分？
出于对完整 Git 工作流的需求，我没有切换。
8. Git 侧边标记 (Git Signs)
| 常规插件 | Mini.nvim 替代品 | 切换结果 |
|---|---|---|
| gitsigns.nvim | Mini.diff | 切换成功 |
体验与分析：
小问题： 尽管文档声称默认使用行号列（number column） ，但它却默认使用了标记列（sign column） 。我需要手动设置才能符合预期。
键位绑定问题： 它似乎自动添加了以 g. ****开头的键位绑定。我强烈反对插件在未经我明确要求或手动配置的情况下，自动添加键位绑定。
保留原因： 我最终保留了 Mini.diff，仅仅是因为我喜欢使用行号列 来标记 Git 差异代码块（hunks），从而将标记列 专门留给 LSP 诊断信息。
9. LSP 通知与诊断 (LSP Notifications)
| 常规插件 | Mini.nvim 替代品 | 切换结果 |
|---|---|---|
| fidget.nvim | Mini.notify | 未切换 |
体验与分析：
Mini.notify 的一个关键问题是：通知文本默认不进行对齐（justified） 。
可读性问题： fidget 会将文本对齐到虚拟文本（virtual text）所在的一侧。Mini.notify 缺乏对齐，使得快速滚动的文本难以阅读。
定制化困境： 我原本非常看好这个小型功能。但为了让它正常工作并正确格式化 LSP 文本，我感觉自己需要编写的代码量，几乎可以自己创建一个新的浮动窗口了。
实际效果： 在大型项目、或是有错误的工程中观察 LSP 加载和报错信息时，Mini.notify 在传达正在发生的事情方面基本无用。
因此，我没有切换。
使用过程中的小槽点 (Nits)
在使用 Mini.nvim 插件集的过程中，我也发现了一些可以改进的小地方：
默认启用图标
所有的 Mini 插件默认都启用图标 。要知道，图标需要打了补丁的字体（patched fonts） 。
令人不解的是，禁用图标的配置方式非常复杂，需要传递一个完整的函数（例如 content = { prefix = function() end }），而不是简单的 icons = false 这样的布尔值开关。
文档问题
部分文档内容有些冗长，偶尔难以跟进其思路，但总的来说还是能找到所需信息。
值得称赞的是，MiniMax 的功能对比部分甚至比官方文档更有帮助，尤其是其提供的功能集与主流插件的对比非常实用。
总结：总体评估与未来展望
通过这次"配置瘦身"尝试，我得出了以下结论：
-
小型插件的胜利： 我非常满意地用 Mini 版本的插件替换掉了好几个小型功能插件（如启动页、词语高亮、键位提示等）。
-
核心功能仍需完善： 对于一些核心且复杂的功能（如文件浏览、模糊查找、Git 核心操作），我感到有些遗憾，因为它们仍无法替换掉我习惯使用的那些主流插件。
-
未来展望： 如果 Mini.nvim 能够解决我提到的这些"小槽点"（特别是浮动窗口的默认行为、通知文本的对齐和默认图标设置），我非常乐意尝试构建一个完全基于 Mini 的 Neovim 配置。
Mini.nvim 的理念是正确的，它正在朝着构建一个更合理、更集成化的 Neovim 基础配置迈进，我期待它的后续发展。