ESLint不能规避运行时错误，但能拦截约90%可静态识别的隐患；必须开启eqeqeq、no-constant-condition等规则并设为error级别，配合sonarjs/no-null-dereference和JSDoc类型标注提前暴露空值访问问题。
ESLint 本身不能规避运行时低级错误，但它能拦截其中约 90% 的“编译前可静态识别”错误——前提是规则选得准、配得严、用得对。 运行时错误（比如 Cannot read property 'x' of null）真正爆发在执行阶段，但绝大多数都源于编码时就埋下的静态隐患：错用赋值、漏判空值、误信类型、跳过边界检查。ESLint 的价值，是把这类隐患卡在保存或提交前。
哪些规则必须开，且设为 error 级别
这些规则覆盖了 JS 中最常导致崩溃的几类静态缺陷，启用后无需额外类型标注就能生效：
-
eqeqeq：强制===，堵死if (x == true)或0 == false这类隐式转换陷阱 -
no-constant-condition：报while (true)和if (1)，防止逻辑写死或条件被意外简化 -
no-unreachable：揪出return后面还跟着语句的死代码，这类代码往往意味着分支遗漏或提前退出误判 -
no-fallthrough：switch中每个case必须显式break或/* falls through */，避免隐式穿透引发意外交互 -
no-octal+no-extra-boolean-cast：禁掉八进制字面量和冗余的!!x，减少因语法误解导致的值异常
如何让 null/undefined 访问提前暴露
纯 JS 下无法像 TypeScript 那样做完整流分析，但可通过组合规则+轻量标注逼近效果：
- 启用
sonarjs/no-null-dereference（需安装eslint-plugin-sonarjs），它会基于简单控制流推断：比如if (obj) { obj.prop }不报错，但obj.prop直接调用就告警 - 配合
dot-notation规则，强制用点号访问属性，避免方括号访问绕过检查（如obj['prop']不受sonarjs约束） - 对已知可能为空的变量，在 JSDoc 中加
@type {string | null}，sonarjs和@typescript-eslint（即使没 TS 编译）都能利用该信息增强判断
为什么 --fix 总像没起作用
不是 ESLint 坏了，而是你指望它修它修不了的东西：
-
--fix只对标记为 “fixable” 的规则生效，比如semi、quotes、no-unused-vars（仅删声明）、eqeqeq（替换成===）——但no-constant-condition或sonarjs/no-null-dereference永远不会自动修复，因为改逻辑需要人判断 - 编辑器里保存不触发修复？检查 VS Code 设置中是否开了
"editor.codeActionsOnSave": {"source.fixAll.eslint": true} - 命令行跑
eslint --fix没反应？确认路径匹配到了目标文件，且没被.eslintignore拦截；大型项目建议加--cache加速
团队落地时最容易被绕过的三个配置细节
规则写了 ≠ 所有人收到警告 ≠ 问题真被拦住：
-
env配多了：项目是 Node.js 后端，却保留browser: true，结果window不报no-undef，掩盖了本该发现的客户端误用 -
parserOptions.project指向失效：TypeScript 项目启用了@typescript-eslint/restrict-template-expressions这类依赖类型信息的规则，但tsconfig.json路径错或未包含当前文件，规则静默失效——连 warning 都没有 -
globals漏声明：第三方库挂载的全局变量（如__DEV__、APP_ENV）没在配置里标为"readonly"，导致no-undef误报，久而久之大家习惯加// eslint-disable-next-line no-undef，规则形同虚设
真正的准入门槛不在规则数量，而在每条规则是否对应一个明确的崩溃场景，以及配置是否严丝合缝地贴合项目真实环境。一旦某条规则开始频繁被 eslint-disable，就要立刻问：是规则太激进，还是代码本身正在绕过一个真实风险？
