VSCode局部变量补全不靠默认排序，需同时设置"editor.suggest.sortSelectedItems": false和"editor.suggest.localityBonus": true，并用语言作用域配置（如"[javascript]"）生效，否则本地变量权重被历史选择覆盖。
局部变量默认不会自动排在全局建议之前——这是 VSCode 补全排序的常见误解。真正起作用的是 editor.suggest.localityBonus，且它只在启用时才让当前作用域内定义的符号（如 const foo = 1）获得权重加成，但不会“强制置顶”，更不保证压过语言服务器返回的高优先级项（比如 console.log 或类型定义里的方法）。
为什么局部变量经常被“埋”在补全列表第二页
VSCode 1.80+ 已移除 editor.suggestSorting，补全顺序由两部分决定：语言服务器返回的 sortText（后端控制，你改不了），以及客户端对匹配项的动态权重（你能调的只有这部分）。editor.suggest.localityBonus 就属于后者，但它只是“加分”，不是“插队”。如果语言服务器给 Array.prototype.map 返回了极低的 sortText 值，哪怕你写了 let map = () => {}，它也大概率排不上去。
- 局部变量未出现在补全里？先确认它是否被语言服务器识别（比如没写
const/let，或在非顶层作用域但未启用 TS/JS 的语义检查） - 写了
const utils = {...}，但补全里utils.后看不到自己定义的方法？说明语言服务器没正确推导出类型，不是排序问题 - 关闭
editor.suggest.sortSelectedItems是前提，否则你选 5 次myHelper，它下次仍可能被Math.random挤到后面
必须设的两个配置项
仅靠 localityBonus 不够，得配合禁用智能重排才能让“本地性”生效：
-
"editor.suggest.sortSelectedItems": false—— 关键开关，否则历史选择行为会覆盖你对局部作用域的偏好 -
"editor.suggest.localityBonus": true—— 让当前文件、当前函数内声明的变量/函数获得匹配权重提升
这两个要同时写进 settings.json，缺一不可。单独开 localityBonus 效果微弱，因为 VSCode 会在你选中一项后立刻把它“重排”到顶部，把刚加的本地分冲掉。
语言级设置比工作区设置更有效
想让 JS/TS 文件优先响应局部变量，别只改用户级或工作区级 settings.json。直接用语言作用域配置，优先级更高：
{
"[javascript]": {
"editor.suggest.sortSelectedItems": false,
"editor.suggest.localityBonus": true,
"editor.suggest.showFunctions": true,
"editor.suggest.showVariables": true
},
"[typescript]": {
"editor.suggest.sortSelectedItems": false,
"editor.suggest.localityBonus": true,
"editor.suggest.showFunctions": true,
"editor.suggest.showVariables": true
}
}
注意：[javascript] 这类配置会覆盖同名的普通设置，且对 .js / .jsx 文件生效；[typescript] 对 .ts / .tsx 生效。不要写成 "javascript": { ... }（少方括号），那样无效。
容易被忽略的干扰项
即使配置全开，以下情况仍会让局部变量“隐身”：
- 装了 Prettier、Auto Import 等插件——它们可能注入大量全局符号（如自动引入的
React成员），稀释本地项权重；可临时禁用测试 - 文件没被语言服务器索引（比如不在
jsconfig.json/tsconfig.json包含路径内），此时localityBonus无变量可加成 - 输入前缀太短（如只打
m），VSCode 会优先匹配所有含m的全局 API，而非局部变量；稍多输几个字母（如my）再触发补全，效果更明显
真正的瓶颈往往不在排序配置，而在语言服务能否“看见”你的局部定义——补全不是纯前端逻辑，它严重依赖后端分析结果。
