高亮匹配延迟主要由editor.selectionHighlight引发，而非editor.occurrencesHighlight；关闭前者可显著提升感知速度，后者默认带300ms防抖属合理节流。
高亮匹配延迟由
和
共同影响
VSCode 默认对括号配对和符号出现位置都做高亮，但两者触发机制不同：括号匹配是即时同步的，而符号出现高亮（比如选中一个变量名后高亮所有同名引用）有内置防抖，约 300ms 延迟。这不是卡顿，是故意加的节流——避免光标移动或快速打字时频繁重绘。
控制括号/花括号/方括号的实时匹配线，设为
或
可开关，但它不控制文本选中后的高亮
才管选中变量、函数名后的全文高亮，它默认开启，但延迟不可直接配置
真正能“提速”的其实是关掉某些干扰项：比如禁用
（它会高亮相同选中文本的其他实例，和 occurrences 不是一回事，但视觉重叠易被误认为延迟）
想让高亮更快？优先关掉
很多人调了半天
，其实真正在拖慢感知的是
—— 它在你双击选中一段文字（比如
）后，会搜索所有完全相同的字符串，包括注释、字符串字面量里的内容，匹配范围大、开销高，且没有防抖。
在设置里搜
，把
设为
保留
为
，它只作用于语义符号（Symbol），比如函数定义、变量声明，响应更快也更准
重启编辑器或重载窗口（
→
）才能生效
插件冲突是隐藏延迟源，尤其 ESLint / Prettier / TypeScript 插件
高亮本身不卡，但如果你开了实时校验类插件，它们会在选中变量后触发符号解析、类型检查甚至 AST 遍历，间接拖慢高亮渲染。典型表现是：刚打开文件时高亮快，编辑几分钟后变慢；或者只在 .ts 文件里延迟明显。
VSCode 1.118
微软正式发布 Visual Studio Code 1.118 版本 。本次更新重点强化了 AI 开发体验与企业管理能力，其中最引人注目的是新增 Copilot CLI 远程控制功能，允许开发者通过手机或网页远程监控和接管 AI 会话 。同时，为了提高 AI 的运行性价比，新版本优化了令牌缓存策略以降低成本 。此外，1.118 版还引入了 Chronicle 本地历史追踪、TypeScript 7.0 支持以及更严格的企业级访问管控 。
下载
临时禁用
、
、
插件，观察高亮是否变灵敏
检查
是否设为
，这个选项会让 TS 语言服务在后台疯狂扫描 node_modules，影响整体响应
大型项目建议关闭
（自动补全里显示普通单词），它会加重词频分析负担
别碰
，它和高亮无关
这个配置常被误搜出来，但它只控制代码补全弹窗的延时（比如输入
后等多久出
提示），和选中高亮完全无关。改了也不会让高亮变快，反而可能让补全变得更“急躁”或更“迟钝”。
除非你真在调补全体验，否则别动
同理，
是旧版配置，VSCode 1.80+ 已弃用，设了也没效果
真正影响高亮性能的底层参数（如
）往往藏在语言特定设置里，比如
这种路径式配置
实际响应速度取决于你当前文件的语言模式、打开的标签页数量、以及有没有在后台跑测试或构建任务。高亮不是越快越好，太快反而干扰视线——VSCode 的节流设计是有道理的。
editor.matchBracketseditor.occurrencesHighlighteditor.matchBrackets"always""never"editor.occurrencesHighlighteditor.selectionHighlighteditor.selectionHighlightoccurrencesHighlighteditor.selectionHighlighthandleClickselection highlighteditor.selectionHighlightfalseeditor.occurrencesHighlighttrueCtrl+Shift+PDeveloper: Reload WindowESLintTypeScript TSLintPrettiertypescript.preferences.includePackageJsonAutoImports"auto"editor.suggest.showWordseditor.quickSuggestionsDelayconconsoleeditor.quickSuggestionsDelayeditor.delayeditor.inlayHints.enabled"typescript.preferences.includePackageJsonAutoImports"