VSCode本身不支持插件直接标记“废弃代码模块”，需人工定义并交叉验证：全局搜索关键词、检查package.json废弃字段、用Shift+F12查引用；但动态加载、配置驱动、测试/CI脚本中的调用易被遗漏，必须结合grep、脚本检查和运行时错误验证。
VSCode 本身没有“依赖分析插件”能识别废弃代码模块
VSCode 不提供、也不支持任何插件直接标记“废弃的代码模块”——它没有内置的废弃语义模型，也不会扫描你写的 utils/legacy 或 deprecated-api.ts 这类命名约定。所谓“识别废弃模块”，本质是人工定义 + 工具辅助验证的过程，不是一键扫描就能出结论。
真正能帮上忙的是三类已有能力的组合
别搜“废弃模块分析插件”，那基本是营销标题。实际有效路径只有三条：
- 用
Ctrl+Shift+F全局搜索关键词：deprecated、@deprecated、LEGACY、OLD_，配合正则\/(legacy|deprecated|v1)\/快速定位目录或文件路径 - 检查
package.json里是否有"deprecated": true字段（npm 官方支持），或看description是否含DEPRECATED（很多包靠这个提示） - 对 TypeScript 项目，打开一个疑似废弃的模块，把光标停在导出名上，按
Shift+F12—— 如果“查找所有引用”结果为空，且全局搜不到import.*from.*它的语句，才初步说明它可能已断连
为什么“查找所有引用”查不到 ≠ 模块真废弃
这是最容易踩的坑：语言服务器根本不知道你写的配置驱动型模块、Webpack require.context 动态加载、或通过 window.MyLegacyModule 挂载的全局对象。这些都逃逸在静态分析之外。
-
eval()、Function()、字符串拼接的require('mod' + 'ule')—— 所有 LSP 都放弃追踪 - Vue Options API 中的
methods: { oldHandler() {} }，旧版 Vetur 或非 setup() 写法，反向引用不会被建模 - 测试文件（
__tests__/或*.spec.ts）里调用了它，但你没把测试目录加进tsconfig.json#include，Shift+F12就查不到 - CI 脚本或部署工具（如 GitHub Actions 的
deploy.yml）里 require 了它，但 VSCode 根本不索引 YAML
想安全下线模块？必须交叉验证这三点
删之前不验证这三项，90% 会出线上问题：
- 在 VSCode 终端运行
grep -r "oldModule" . --include="*.js" --include="*.ts" --include="*.json"，确认没漏掉 config、schema、mock 数据里的引用 - 检查
package.json#scripts，比如"prebuild": "node scripts/cleanup-old.js"这种脚本里是否还依赖它 - 打开开发者工具（
Ctrl+Shift+P→Developer: Toggle Developer Tools），清空 Console，刷新页面或触发相关功能，看是否有ReferenceError: oldModule is not defined
最常被误判为“废弃”的，其实是构建时注入的 polyfill、Mock 接口桩、或仅在 SSR 环境中使用的模块——它们从不在客户端源码里 import，但删了就崩。
