Vim 工程手册
Vim 的优势不是“到处都有”，而是坏环境里仍能降级
服务器上偶然存在一个 vi 命令，不代表它就是团队支持的 Vim。它可能是兼容实现、精简编译或发行版多年未更新的包，缺少 terminal、job、channel、clipboard、Python 等特性。反过来，一份装了几十个插件的个人配置也不能代表 Vim 的最低能力：插件源不可达、终端不支持颜色或远端没有语言服务器时，必须仍能编辑、搜索、运行项目命令和读取错误。
Neovim 的 XDG 配置、Lua、内置 LSP、provider 与 :checkhealth 有独立运行模型，相关配置见 Neovim 工程手册。两者继承大量命令和编辑语义，但不应共享一份未经条件判断的配置，也不能把 vim 与 nvim 软链接互换后称为兼容验证。
先识别实际二进制与编译特性
Vim 官方下载页给出当前稳定系列和各平台入口。团队优先使用操作系统或组织已经治理的软件源；需要固定 patch level、GUI 或特殊编译特性时再归档官方制品或自建包。安装记录至少保存命令解析路径、版本、patch、编译器和关键 feature：
command -v vim
vim --version
vim --clean +'set runtimepath?' +qWindows 用 Get-Command vim 定位，WinGet、安装包与 Git for Windows 自带 Vim 可能同时存在。macOS 的系统 Vim、Homebrew Vim 和 MacVim 也可能冲突；Linux 则要区分 vim-minimal、vim-nox、GUI 包和发行版 backport。支持基线不能只写“安装 Vim 9”，而要写实际 package、更新责任与需要的 +feature。
安装后先用一个空文件测试打开、写入、退出，再运行 :version、:echo $VIMRUNTIME 和 :set runtimepath?。还要在团队常用的本地终端、tmux 和 SSH 入口各打开一次中文、长行与 diff 样本，记录编码、颜色、退格和组合键差异。卸载前确认 vim、vi、view 等 alternatives 或 shell alias 的归属，避免删除团队包后系统仍解析到另一份二进制。配置与 swap/undo 数据另行清理，不让卸载命令顺带删除未知个人文件。
--clean 是基准，不是另一个日常配置
Vim 启动文档说明 -u NONE 会跳过初始化并停止加载插件，--clean 则更接近“加载 Vim 默认值、排除用户 runtimepath、禁用 viminfo”的可用干净环境。两者用途不同：
vim --clean sample.txt
vim -u NONE -U NONE -i NONE --noplugin sample.txt第一条用于确认默认 Vim 是否能正常编辑；第二条更适合把用户配置、GUI 配置、viminfo 与插件全部移出变量。若两者都失败，优先调查终端、文件权限、二进制或系统 runtime；只有日常启动失败，才进入 vimrc、plugin 与持久状态排查。
团队必须保留这条降级路线。启动脚本不应强制联网更新插件，也不应在插件管理器失败时中止整个编辑器。远程机器上只要 clean 模式可用，就能打开日志、修改受控配置、使用 :grep/quickfix 和退出；这比“完整配置必须到处一致”更可靠。验收时还要在只读文件、无网络和缺少一个可选插件的条件下各启动一次，确认提示清楚且编辑能力没有被连带阻断。真正的最低环境应在依赖不齐时降级，而不是用一串 Vimscript 异常占满屏幕。
找到真正生效的 vimrc
Vim 会按平台与启动参数查找系统和用户初始化文件。不要靠记忆猜 ~/.vimrc，直接在运行实例取证：
:echo $MYVIMRC
:echo $VIMRUNTIME
:set runtimepath?
:set packpath?
:scriptnames
:verbose set tabstop?$MYVIMRC 告诉你实际读取的主配置，:scriptnames 展示已 source 的脚本，:verbose set 能追到最后修改某项 option 的文件和行号。一个值“不听配置”时，这组证据比反复追加 set 更快。
配置仓库建议按入口、通用 option、mapping、autocommand、filetype、plugin 与机器覆盖拆分。vimrc 中只 source 仓库内已知路径；本机差异单独存在不提交的 local 文件，并在主配置中以 filereadable() 明确加载。主题和按键属于个人偏好，format、项目命令与安全默认需要团队评审。
Vimscript 本身能执行 shell、读环境和访问网络。dotfiles 与普通代码仓库一样需要来源、owner、review、版本和回滚；从网上复制一段配置不会因为放在文本文件中就变得安全。
项目根不能靠“打开文件时刚好在哪”
Vim 的当前工作目录、buffer 所在目录与 Git/project 根可以不同。makeprg、grep、tags、formatter 和测试命令如果默默继承启动目录，同一文件从仓库根或子目录打开会产生不同结果。先在状态诊断中同时打印：
:pwd
:echo expand('%:p')
:echo finddir('.git', expand('%:p:h').';')
:set makeprg?
:set errorformat?团队配置要选择明确策略：全局 cwd 始终由用户控制；或进入 buffer 时按 marker 推导 root；或只把 root 传给具体命令而不执行全局 :cd。最后一种副作用最小。无论哪种，都应让状态栏或诊断命令能显示当前 root，避免插件各自向上搜索后得到三套 workspace。
仓库的构建事实仍是 Makefile、Wrapper、task script 或 package manager。Vim 可以发现并调用，不能把关键参数只藏在 :set makeprg=... 的个人 vimrc 中。项目接入的第一步是在外部终端成功执行正式命令，再让 Vim 调用同一个入口。
Quickfix 把命令输出变成可跳转证据
Vim quickfix 文档描述了 :make 如何调用 makeprg，再用 errorformat 解析错误。它不是一个“错误列表 UI”，而是把外部工具输出、文件、行号和退出结果带回编辑循环的协议层。
以仓库脚本为例，可在项目 filetype 或受控配置中指定命令：
setlocal makeprg=./scripts/check运行 :make 后用 :copen、:cnext、:cprevious 检查错误。不要在 makeprg 中拼真实 token 或复杂 shell 管道；路径含空格、Windows shell 与命令转义都要用代表项目实测。输出格式不稳定时，优先让仓库脚本提供机器可解析格式，再调整 errorformat。
正向验证是故意制造一个编译或 lint 错误，确认 quickfix 指向当前工作树的准确文件与行号；修复后再次 :make，列表清空且外部命令退出码成功。反例是从子目录启动 Vim，若命令找不到 Wrapper 或跳到另一个同名路径，说明项目根仍未受控。恢复 root 策略后同一错误应稳定复现和消失。
运行、测试和调试不必都由插件接管。Vim 原生 terminal、:make 与 quickfix 足以覆盖最低入口；语言调试器可以由外部终端运行，必要时再引入插件。团队先支持可观察的命令，再支持更复杂的 UI。
原生 package 只解决加载位置，不解决版本治理
Vim 的 pack/*/start/* 会自动进入加载链，pack/*/opt/* 需要 :packadd。这套机制无需插件管理器，但不会自动固定提交、验证来源或生成锁文件。把一个 Git 仓库 clone 到 start 后，它就会以编辑器权限执行；删除 vimrc 中的配置行也不会阻止它自动加载。
团队可以选择受控 vendor、Git submodule 或能生成精确 lock 的管理器，重点不是工具名，而是配置清单与版本证据一起评审。升级一次只改少量插件，运行启动时间、代表文件、quickfix 和项目命令；失败时能切回上一个 commit/lock。插件编译产物、下载 cache 与源码目录分别设置清理边界。
插件权限与 Vim 进程相同，可以读取源码、环境变量、SSH agent socket、凭证文件，启动外部进程并访问网络。来源、维护状态、许可证、构建脚本与数据发送都属于准入审查。AI、遥测和云补全插件还要进入独立数据边界评估，不能只看仓库 star 数。
项目本地配置必须默认不可信
Vim 的 modeline 能从文件首尾改变部分 option；启用 exrc 后还可能读取当前目录的 .vimrc 或 .exrc。这些都是仓库内容影响编辑器行为的入口。陌生仓库、下载样例和代码审查分支不应被默认执行。
modeline 只保留必要且受限制的格式选项，保持表达式能力关闭；本地 exrc 若确需使用，必须启用安全约束、限定可信仓库并审查内容。更稳的团队方案是把 formatter、lint 和构建入口放在仓库脚本或标准配置中，由用户明确调用，而不是进入目录就自动 source 任意脚本。
autocommand 也会在 BufRead、DirChanged、FileType 等事件执行。排查“打开文件就变目录、运行命令或写文件”时用 :verbose autocmd <event> 查来源。安全问题不能靠 silent! 隐藏；应移除来源或收紧触发范围。
凭证只通过外部 credential helper、受控环境或短期身份进入被调用工具。vimrc、session、shada/viminfo、命令历史和终端 scrollback 都可能留下敏感参数，项目示例使用占位符，不把生产地址和 secret 写进 mapping。
SSH 场景先保证终端语义，再谈完整体验
远端 Vim 在远端读取文件、执行插件和项目命令，本地终端只负责显示与输入。颜色异常、按键延迟、剪贴板不可用或 Alt 键失效，通常来自 $TERM、terminfo、tmux、SSH 延迟或本地终端编码，不是项目配置本身。
最低远端基线包含：UTF-8 文件可正确读写；搜索、diff、quickfix 可用；不依赖系统剪贴板；插件源断开时 clean 模式可启动；退出后没有遗留构建或调试进程。远端缺失 feature 时明确降级，不在共享服务器上临时编译一份无人维护的 Vim。
SSH agent、Git 凭证与代理转发会扩大远端权限。只有确有需要的主机才转发，并验证插件不会把 socket 或环境写入日志。生产主机通常只允许最小编辑和诊断，不安装完整个人插件集，更不把项目本地配置设为自动信任。
文件恢复也要纳入最低基线
终端编辑器常被用于网络不稳、主机异常或紧急修复，swap 与 undo 的位置因此不能靠默认值碰运气。用 :swapname、:set directory?、:set undodir? 和 :set undofile? 确认恢复文件落点；模拟一次未正常退出，再从同一文件恢复并比较内容。共享主机上的恢复目录要有正确权限和清理周期，避免其他账号读取文件片段。恢复成功后明确删除过期 swap，不把“发现交换文件”的告警永久训练成无条件忽略。
故障恢复从启动时间和脚本来源入手
启动慢时用 --startuptime 保存阶段耗时，结合 :scriptnames 找到具体插件；启动报错则先比较 --clean、-u NONE 与正常模式。某个 option 异常用 :verbose set，某个 mapping 异常用 :verbose map，某个事件异常用 :verbose autocmd。这些证据能把“配置有问题”缩小到一行来源。
插件升级后命令消失，先核对 runtimepath、package 位置、lock/commit 和加载条件；不要同时升级 Vim 与全部插件。quickfix 行号错误时保存原始命令输出，检查 cwd、errorformat 与路径编码。swap、undo 和 viminfo 增长时分别确认目录、保留周期和是否仍有打开文件，不用递归删除整个用户配置目录。
回滚顺序从小到大：恢复单个配置 commit；回退插件 lock；切回上一 Vim package；最后才用新的空配置目录重建。任何清理前先备份未提交 vimrc 与项目修改。验证恢复后，clean 模式与团队配置模式都应能打开代表项目，:make 正反实验通过，且没有未知外部进程。
团队支持的是可复现入口，不是统一按键
Vim 适合终端优先、远程维护、需要低依赖降级和偏好键盘工作流的场景。它的架构成本集中在配置语言、插件供应链、外部工具发现和终端差异。团队不必统一主题和全部 mapping，但要统一项目命令、root 规则、安全默认、插件准入与故障收集方法。
基线记录 Vim 来源与 feature、配置仓库版本、插件锁、批准的外部工具、项目 marker、quickfix 验证、远端限制、升级 owner 和退出条件。新人从干净账号 clone dotfiles 后，既能用受控配置，也能随时退到 --clean；删除 Vim 后，仓库构建仍由命令行成立。这样的环境才配称为工程工具，而不只是某个人多年积累的一套手感。