webstorm 的代码分析提示是实时拦截潜在 bug 的第一道防线，通过波浪线颜色区分严重性（红/黄/灰）、小灯泡提供修复选项，并支持定制检查强度以聚焦关键问题。
WebStorm 的代码分析提示不是装饰，是实时帮你拦截潜在 bug 的第一道防线。它默认开启但常被忽略，关键在理解哪些提示真该处理、哪些可抑制，以及怎么让提示更准更及时。
怎么看懂 WebStorm 底下那些波浪线和小灯泡
波浪线颜色直接对应问题严重性：红色 是语法错误或类型冲突（如调用不存在的方法），黄色 是警告（如未使用的变量、过时的 API），灰色 通常是弱提示（如可选链建议、未导出的函数）。小灯泡（?）点开后显示具体操作：快速修复、禁用此检查、调整检查级别。
- 悬停在波浪线上，看 tooltip 里的
Inspection 'xxx'名称，这是检查项的真实 ID，可在设置里搜它来开关 - 按
Alt + Enter（macOS 是⌥ + ⏎）直接唤出上下文修复菜单，比点灯泡快得多 - 部分提示带「More info」链接，点开会跳转到官方文档说明触发条件和修复逻辑
为什么改了代码，波浪线还不消失？常见同步延迟场景
WebStorm 的分析基于后台索引和语义模型，不是纯文本扫描，所以某些修改不会立刻刷新提示——尤其涉及跨文件类型推导、第三方库类型定义（@types）、或 TypeScript 配置变更后。
- 改完
tsconfig.json后，必须手动触发File → Reload project from disk或点击右下角的TS图标选择Restart TypeScript Service - 引入新 npm 包但没装
@types/xxx，类型提示可能缺失或误报；装完后需等 WebStorm 自动检测，或手动执行File → Invalidate Caches and Restart → Just Restart - 使用
declare module扩展全局类型时，确保该声明文件被tsconfig.json的include或files覆盖，否则不参与分析
如何定制检查强度：关掉噪音，留下关键提示
默认检查太“唠叨”？别全局关，而是分层控制。比如 Unused symbol 在开发阶段有用，但单元测试里常有故意未调用的 mock 函数，这时应局部抑制而非关掉整个检查。
- 在代码行末加
// @ts-ignore（TS）或// noinspection JSUnusedLocalSymbols（JS）可单行禁用特定检查 - 进
Settings → Editor → Inspections，按语言或严重级别筛选，比如把JavaScript → General → Unresolved variable从Warning降为Weak Warning，保留红色错误但减少干扰 - 对整个目录禁用某检查：右键文件夹 →
Refactor → Suppress for directory，适合node_modules或生成代码目录
真正影响健壮性的提示往往藏在黄色波浪线里——比如 Promise is not handled 或 Unsafe assignment to 'any'。它们不像红色错误那样阻断运行，却在上线后突然爆发。别依赖“先跑通再说”，让 WebStorm 的提示成为你写代码时的实时 peer review。
