webstorm不提供静态依赖图谱，其“external libraries”仅粗略映射package.json，无法反映真实引用关系；需结合ctrl+click跳转、补全提示、find usages及终端命令（如npx depcheck、npm ls）验证依赖有效性。
WebStorm 本身不提供模块依赖的静态图谱或可视化分析功能，它不会像 depcheck 或 npm ls --depth=0 那样输出“哪些包未被使用”或“哪些 import 路径失效”。但你可以借助内置能力+少量外部命令，快速定位和验证依赖问题。
为什么直接看 WebStorm 的“External Libraries”不靠谱
WebStorm 在项目打开时会扫描 node_modules 并把所有顶层包列在 “External Libraries” 下，但这只是基于 package.json 的粗略映射，不是运行时或 AST 级的真实引用关系。比如：
-
lodash出现在package.json中，但项目里根本没写import或require—— WebStorm 仍会把它标为“已解析” -
react-router-dom被import { useNavigate } from 'react-router-dom'引用，但 WebStorm 可能因类型定义缺失或路径别名配置错误，标红提示“Cannot resolve symbol”，实际代码却能正常运行 - 使用了动态
import()加载的模块（如路由级 code-splitting），WebStorm 很难静态推导，也不会出现在“Find Usages”结果里
用 WebStorm 快速验证 import 是否真正生效
重点不是“有没有列出来”，而是“能不能跳转、有没有类型提示、会不会报错”。实操建议：
- 把光标放在任意
import语句的模块名上（例如axios），按Ctrl + Click（Mac 为Cmd + Click）—— 如果跳转失败，说明 WebStorm 没识别到该包的入口；检查node_modules/axios/package.json是否有"main"或"exports"字段，以及是否启用了Node.js Core库支持（Settings → Languages & Frameworks → Node.js and NPM） - 在
import行末尾加个分号，然后按Ctrl + Space触发补全 —— 如果弹出该模块导出的函数/类列表（如get、post），说明类型定义已加载；否则可能缺少@types/xxx或包自身未带类型 - 右键点击模块名 →
Find Usages—— 注意结果是否包含真实调用点；若只有import行本身，大概率是未实际使用（但需排除动态引入场景）
配合终端命令做轻量级依赖审计
WebStorm 内置终端（Alt + F12）可直接运行以下命令，比图形界面更准：
- 查未使用的依赖：
npx depcheck --ignore-bin-package—— 它扫描import/require语句，对比package.json，输出疑似冗余项 - 查版本冲突：
npm ls react（把react换成你要查的包名）—— 显示该包在依赖树中的所有出现位置和版本，一眼看出是否多版本共存 - 查路径解析是否异常：
node -e "console.log(require.resolve('lodash'))"—— 如果报错Cannot find module，说明 Node.js 层面就找不到，WebStorm 的标红只是结果，不是原因
真正容易被忽略的是：WebStorm 的依赖感知高度依赖 tsconfig.json 或 jsconfig.json 中的 "baseUrl" 和 "paths" 配置。如果用了别名（如 @/utils），但配置文件没正确声明，那么所有基于该别名的 import 都会失效——此时 WebStorm 不会报错，但跳转和补全全部失灵，必须手动核对配置文件内容与实际目录结构是否一致。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
