高亮匹配延迟主要由editor.selectionHighlight引发，而非editor.occurrencesHighlight；关闭前者可显著提升感知速度，后者默认带300ms防抖属合理节流。
高亮匹配延迟由 editor.matchBrackets 和 editor.occurrencesHighlight 共同影响
VSCode 默认对括号配对和符号出现位置都做高亮，但两者触发机制不同：括号匹配是即时同步的，而符号出现高亮（比如选中一个变量名后高亮所有同名引用）有内置防抖，约 300ms 延迟。这不是卡顿，是故意加的节流——避免光标移动或快速打字时频繁重绘。
-
editor.matchBrackets控制括号/花括号/方括号的实时匹配线，设为"always"或"never"可开关，但它不控制文本选中后的高亮 -
editor.occurrencesHighlight才管选中变量、函数名后的全文高亮，它默认开启，但延迟不可直接配置 - 真正能“提速”的其实是关掉某些干扰项：比如禁用
editor.selectionHighlight（它会高亮相同选中文本的其他实例，和 occurrences 不是一回事，但视觉重叠易被误认为延迟）
想让高亮更快？优先关掉 editor.selectionHighlight
很多人调了半天 occurrencesHighlight，其实真正在拖慢感知的是 editor.selectionHighlight —— 它在你双击选中一段文字（比如 handleClick）后，会搜索所有完全相同的字符串，包括注释、字符串字面量里的内容，匹配范围大、开销高，且没有防抖。
- 在设置里搜
selection highlight，把editor.selectionHighlight设为false - 保留
editor.occurrencesHighlight为true，它只作用于语义符号（Symbol），比如函数定义、变量声明，响应更快也更准 - 重启编辑器或重载窗口（
Ctrl+Shift+P→Developer: Reload Window）才能生效
插件冲突是隐藏延迟源，尤其 ESLint / Prettier / TypeScript 插件
高亮本身不卡，但如果你开了实时校验类插件，它们会在选中变量后触发符号解析、类型检查甚至 AST 遍历，间接拖慢高亮渲染。典型表现是：刚打开文件时高亮快，编辑几分钟后变慢；或者只在 .ts 文件里延迟明显。
- 临时禁用
ESLint、TypeScript TSLint、Prettier插件，观察高亮是否变灵敏 - 检查
typescript.preferences.includePackageJsonAutoImports是否设为"auto"，这个选项会让 TS 语言服务在后台疯狂扫描 node_modules，影响整体响应 - 大型项目建议关闭
editor.suggest.showWords（自动补全里显示普通单词），它会加重词频分析负担
别碰 editor.quickSuggestionsDelay，它和高亮无关
这个配置常被误搜出来，但它只控制代码补全弹窗的延时（比如输入 con 后等多久出 console 提示），和选中高亮完全无关。改了也不会让高亮变快，反而可能让补全变得更“急躁”或更“迟钝”。
- 除非你真在调补全体验，否则别动
editor.quickSuggestionsDelay - 同理，
editor.delay是旧版配置，VSCode 1.80+ 已弃用，设了也没效果 - 真正影响高亮性能的底层参数（如
editor.inlayHints.enabled）往往藏在语言特定设置里，比如"typescript.preferences.includePackageJsonAutoImports"这种路径式配置
