代码高亮和行号需按场景精准配置：必须先启用 filetype 检测（filetype plugin indent on），再开启 syntax on；行号推荐同时启用 set number 与 set relativenumber；否则易导致高亮失效、行号不可读或性能下降。
代码高亮和行号不是“开了就行”，而是要分场景配——开错反而干扰阅读、拖慢启动、甚至破坏插件行为。
语法高亮必须在 filetype 检测之后启用
很多人直接写 syntax on 就以为万事大吉，但 Vim 启动时若没识别出文件类型，syntax on 会加载默认语法（比如纯文本），后续打开 .py 或 .js 文件也不会自动切换。正确顺序是：
- 先禁用兼容模式：
set nocompatible - 再开启 filetype 检测链：
filetype plugin indent on - 最后才开高亮：
syntax on
漏掉 filetype plugin indent on，不仅语法高亮可能失效，连 Python 的缩进逻辑、JSON 的折叠规则也会不工作。某些发行版预装的 tiny-vim 还默认关闭 filetype，得确认安装的是完整版 vim（Ubuntu 上运行 sudo apt install vim）。
行号显示策略要匹配操作习惯
set number 和 set relativenumber 不是二选一，而是可以共存——Vim 支持同时开启，当前行显示绝对行号，其余行显示相对行号。这对跳转类操作（如 5j、3k、:12）最友好：
- 只开
set number：适合调试时记行号、写文档引用位置 - 只开
set relativenumber：适合高频移动（如配合gj/gk跳可视行），但:123这种跳转会失效 - 两个都开：
set number+set relativenumber：推荐日常使用，无冲突
注意：如果用了插件如 vim-airline 或 lightline，它们默认从 number 取值，relativenumber 不影响状态栏显示。
高亮/行号相关常见错误现象
这些表现往往不是配置写错了，而是加载时机或依赖缺失：
-
Unknown function: syntax错误：说明 Vim 编译时没启用+syntax特性（tiny-vim 常见），运行vim --version | grep syntax看是否输出+syntax - 打开 .py 文件没高亮，但
:syntax on手动执行后有了：说明filetype没触发，检查是否漏了filetype plugin indent on或被set nocompatible之前的内容干扰 - 行号颜色太淡、看不清：不是配置问题，是 colorscheme 本身没定义
LineNr高亮组，可手动加一行：hi LineNr ctermfg=242 guifg=#666 - 开启
relativenumber后光标所在行数字突然变大：那是当前行号（绝对值），不是 bug，是设计如此
性能与兼容性容易被忽略的点
高亮和行号本身开销不大，但组合不当会放大副作用：
-
set cursorline+set relativenumber在大文件（>10k 行）中滚动明显卡顿，因为每行都要重算相对值并重绘高亮行 - 某些终端（如 tmux 内嵌的）不支持 256 色，
colorscheme若强行用 RGB 值（如guifg=#ff0000），高亮会降级成灰阶甚至消失，建议优先选cterm兼容方案 - Windows 下
_vimrc若含中文注释且保存为 UTF-8 with BOM，可能导致filetype解析失败——改用 UTF-8 no BOM 或把注释移到英文环境里
真正麻烦的从来不是加一行 syntax on，而是搞清它在哪加、谁先加载、谁依赖它、以及终端/插件/文件类型怎么跟它咬合。一个 .vimrc 能跑，不等于它在所有项目、所有终端、所有 Vim 版本里都稳。
