第一反应应确认语言服务器是否运行，因它一挂所有语义功能（跳转、引用、补全）即退化为不可靠的文本匹配；需通过typescript: open ts server log查日志，若为空或卡在starting则执行typescript: restart ts server。
语言服务器是否在运行
“Find All References”或F2重命名失效，第一反应不该是改代码，而是确认TypeScript/JavaScript语言服务有没有真正跑起来。它一挂，所有语义级功能（跳转、引用、补全）都会退化成纯文本匹配——看着像在工作，实际漏得离谱。
打开命令面板（Ctrl+Shift+P），输入并执行TypeScript: Open TS Server Log。如果日志里全是空的，或者最后一行停在Starting TS Server没后续，说明服务根本没起来。这时候再试TypeScript: Restart TS Server，而不是直接关编辑器。
- Mac 用户注意：
Cmd+Shift+P后输命令时别手滑按成Cmd+Space，那会唤出系统 Spotlight - 终端里跑
ps aux | grep tsserver能看到进程是否存在；没进程就不是卡顿，是压根没启动 - 如果重启后日志里反复出现
TypeError: Cannot read property 'map' of undefined，大概率是tsconfig.json里某个路径配置错了，比如"include"指向了不存在的目录
符号本身能否被正确定义
光标放在函数/变量上，按 Ctrl+Click 跳不到定义？那“查找所有引用”必然不准——连源头都找不到，还怎么找下游。
常见断点位置：
-
jsconfig.json或tsconfig.json中"skipLibCheck": true开着，但你又用了未声明类型的第三方模块（比如直接import { foo } from 'lodash'却没装 @types/lodash） - 变量是通过
const { x } = obj解构出来的，但obj类型推导失败，LSP 就不会把x当作可追踪符号 - JS 文件里没写 JSDoc 注解，且
jsconfig.json没开"checkJs": true，LSP 默认当它“不可信”，跳过深度分析
验证方式：新建一个最小文件，只写 function test() {} test()，看能否跳转和查引用。能，说明问题出在项目配置；不能，说明语言服务整体异常。
路径别名和模块解析是否生效
用 @utils/foo 这种别名导入，却查不到引用？不是功能坏了，是 LSP 根本不知道 @utils 指向哪。它不会自动读 webpack.config.js 或 vite.config.ts，只认 tsconfig.json 的 "paths" 和 "baseUrl"。
检查你的 tsconfig.json 是否有类似配置：
{ "compilerOptions": { "baseUrl": ".", "paths": { "@utils/*": ["src/utils/*"] } }, "include": ["src/**/*"] }
-
"baseUrl"必须是字符串，不能是./或""；设成"."最稳妥 -
"paths"的 key 和 value 都要以/*结尾，否则匹配不上 - 如果项目是 JS + jsconfig.json，对应字段是
"compilerOptions"下的同名项，但jsconfig.json不支持"types"字段，类型提示会弱很多
扩展冲突是否在后台干扰
某些扩展会在你不注意时悄悄调用 vscode.executeReferenceProvider，比如旧版 Bracket Pair Colorizer、某些 AI 补全插件、甚至颜色主题插件。它们一触发，就会中断 C++ 或 TS 语言服务器正在做的引用分析，导致结果不全、CPU 狂飙、状态栏反复显示“索引中……”。
快速验证方法：
- 用
code --disable-extensions启动 VSCode（终端里执行），只开默认 TS 支持，测试引用功能是否恢复 - 如果恢复，进扩展面板（
Ctrl+Shift+X），禁用所有非必要扩展，再一个个开，重点盯住名字带 “AI”、“CodeLens”、“Color”、“Formatter” 的 - 特别留意那些在设置里有
enableReferences或autoDetect开关的插件，它们可能默认就劫持了引用逻辑
真正麻烦的不是功能失效，而是它失效得不彻底——有时能查到 80% 的引用，剩下 20% 死活不出现，这种半残状态最消耗排查时间。根源往往不在代码，而在某次随手加的配置或上周更新的某个插件。
