不能。ESLint是静态分析工具，不执行代码、不感知运行期行为，仅基于AST和规则检查可能引发运行期问题的编码模式，如undefined属性访问、未处理Promise等，但无法预判真实运行时错误。
不能。 ESLint 是静态分析工具，它不执行代码，也不感知运行期行为——所谓“运行期错误提前预判”是常见误解。它能做的，是基于 AST 和规则，在你保存时指出 undefined 属性访问、Promise 未处理、console.log 残留等 *可能引发运行期问题的编码模式*，但绝不是模拟执行或捕获真实异常。
为什么 ESLint 标红不等于运行时报错
ESLint 的检查发生在语法解析阶段，不加载模块、不调用函数、不走控制流。比如以下代码：
const user = getUser();<br>console.log(user.name);
ESLint 可能报 user 可能为 null（靠 @typescript-eslint/restrict-template-expressions 或 no-unused-vars 等规则启发式推断），但它无法知道 getUser() 实际返回什么——那是 TypeScript 类型系统或运行时调试器（如 Chrome DevTools）的事。
- 它不会发现
user.getName()报TypeError: user.getName is not a function - 它不会拦截
fetch('/api').then(res => res.json()).catch(...)中 JSON 解析失败的场景 - 它对异步链中未 await 的 Promise、未清理的定时器等，仅靠有限规则覆盖，非全量检测
哪些“运行期风险” ESLint 确实能拦住
它擅长识别 *已知易错模式*，尤其配合插件后：
-
no-undef：防止访问未声明变量（如拼错documet.getElementById） -
no-console：删掉开发残留的console，避免上线报错或泄露信息 -
no-empty+no-unreachable：减少逻辑空块和死代码，间接降低分支误判概率 -
@typescript-eslint/no-floating-promises：强制await或.catch()，防未处理 Promise rejection -
react-hooks/exhaustive-deps：避免useEffect依赖缺失导致闭包 stale，这是 React 运行期典型 bug 源头
真正想预判运行期错误，得组合其他工具
单靠 ESLint 不够，需分层防御：
- **TypeScript 编译期检查**：
strict模式下，any、undefined访问、函数参数类型不匹配等，比 ESLint 更早更准 - **Jest / Vitest 单元测试**：覆盖边界条件，验证函数在特定输入下的输出，直接暴露运行逻辑缺陷
- **VSCode 的 JavaScript Debugger**：设断点、看 call stack、检查
this绑定，直击执行现场 - **浏览器 DevTools 的 “Pause on caught exceptions”**：哪怕被
try/catch捕获，也能中断定位源头
ESLint 在这个链条里，只负责“写的时候别犯低级错误”，不是“跑的时候别出错”的替身。把它当守门员，别当裁判员。
