如何总结一套基于 ESLint 的团队代码准入规范以规避 90% 的运行时低级错误-js教程-PHP中文网

ESLint不能规避运行时错误，但能拦截约90%可静态识别的隐患；必须开启eqeqeq、no-constant-condition等规则并设为error级别，配合sonarjs/no-null-dereference和JSDoc类型标注提前暴露空值访问问题。

如何总结一套基于 eslint 的团队代码准入规范以规避 90% 的运行时低级错误

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，规则形同虚设