WebStorm死代码检测依赖Unused symbol、Unreachable statement等内置Inspection项，需在Settings→Editor→Inspections中按语言启用；其准确性受tsconfig/jsconfig配置、框架库识别、文件索引范围及ESLint干扰影响。
WebStorm 能直接识别并高亮死代码（如未使用的变量、函数、导入、类成员等），但默认行为受语言类型、检查级别、ESLint 集成状态影响，不是所有“看起来没用”的代码都会被标记——关键看它是否被**静态分析确认不可达或从未被引用**。
死代码检查依赖哪些内置检查项
WebStorm 自带的死代码检测分散在多个 Inspection 中，不叫“Dead Code”一个名字，而是按语义拆分：
-
Unused symbol：标记未被读取/调用的变量、函数、类、方法、参数（JS/TS 默认启用） -
Unreachable statement：标记return、throw、break后面的代码（JS/TS 默认启用） -
Unused import statement：标记未被使用的 ES 模块导入（JS/TS 默认启用，但对import type或仅用于 JSDoc 的导入可能放过） -
Unused label、Unused catch parameter等细粒度项（默认关闭，需手动勾选）
这些检查在 Settings | Editor | Inspections 下按语言展开（如 JavaScript → General），必须处于启用状态才生效。注意：TypeScript 项目中，Unused symbol 的判断会结合 TS 类型系统，比纯 JS 更严格；而 JS 文件若未开启 JSDoc 类型推导，某些“看似未用”的变量可能逃过检测。
为什么有些死代码没被高亮
常见原因不是 WebStorm 漏检，而是它“不敢确定”——静态分析有天然局限：
- 动态属性访问：
obj[variableName]中的variableName若为字符串拼接或变量，WebStorm 无法追踪实际 key，可能放过本该标记的未使用属性 - 全局污染场景：通过
window.xxx = fn或this.xxx = fn暴露的函数，WebStorm 默认不认为它们被“外部引用”，会标为未使用（除非你显式配置了 global scope） - 装饰器或框架元数据：React 组件名、Vue
setup()中的返回值、Angular@Component类，若未被框架扫描逻辑覆盖，可能被误判 - ESLint 优先级干扰：如果同时启用了 ESLint 且其规则（如
no-unused-vars）与 WebStorm 内置检查冲突，后者可能退让——尤其当 ESLint 配置了/* eslint-disable */注释时
此时可临时禁用 ESLint（在 Settings | Languages & Frameworks | JavaScript | Code Quality Tools | ESLint 中关掉 Enable），观察原生高亮是否出现，快速定位干扰源。
如何让死代码提示更准、更早
不靠猜，靠配置和上下文补全：
- 确保项目根目录有
tsconfig.json（TS）或jsconfig.json（JS），且"checkJs": true（JS 项目）已开启——这能让 WebStorm 建立更完整的模块引用图 - 对 Vue/React 项目，在
Settings | Languages & Frameworks | JavaScript | Libraries中添加对应框架库（如vue、react），否则defineComponent或useState的返回值可能被误标为未使用 - 右键文件 →
Inspect Code，范围选当前文件，检查类型勾选Whole project下的JavaScript和TypeScript相关项——比实时编辑时的检查更彻底，能发现跨文件引用断链 - 对确信是死代码但未高亮的语句，把光标放上去按
Alt+Enter，看是否有Suppress for statement以外的选项；如果有Make symbol private或Remove unused symbol，说明 WebStorm 其实识别到了，只是默认未高亮（比如因作用域太深）
真正容易被忽略的是：WebStorm 的死代码判断基于**当前打开的文件集合**。如果你只打开了 a.js，而 b.js 里引用了 a.js 的某个函数，但 b.js 没被索引（比如被 .gitignore 排除或未加入项目结构），那么 a.js 中那个函数就会被当作死代码标红——这不是误报，是你的项目结构本身没告诉 WebStorm “它会被用到”。
