ESLint 强制代码规范，减少低级错误

ESLint 的核心价值远不止于代码格式美化——它通过精准配置高敏感度的静态分析规则（如 no-cond-assign、eqeqeq、sonarjs/no-null-dereference），在编码阶段主动拦截赋值误用、隐式类型转换、空值解构等典型逻辑错误，真正把防线前移到开发源头；而自动修复（--fix）仅适用于格式和部分静态问题，对语义级缺陷无能为力，因此团队落地成败关键在于规则的有效启用、配置链路的严谨闭环（如环境设置、TS项目路径、编辑器识别）以及与Prettier的职责厘清：让Prettier专注“写得整齐”，让ESLint死守“写得安全”，最终实现CI中逻辑错误零容忍的硬性卡点。

为什么 eslint --fix 不能自动修复逻辑错误

ESLint 的 --fix 只能处理格式类问题（缩进、分号、引号）和部分可推断的静态规则（如 no-unused-vars），但对逻辑错误——比如 if (x = 0)（误用赋值而非比较）、for (let i = 0; i （循环中修改数组长度）——它既不识别语义，也无法安全改写。这类问题必须靠规则配置 + 开发者理解 + 配合类型检查。

真正起作用的是启用高敏感度的静态分析规则，而不是依赖自动修复：

• no-cond-assign：拦截 if (x = y) 这类条件中意外赋值
• no-constant-condition：报错 while (true) 或 if (1) 等恒真/假条件（除非显式写成 /* eslint-disable no-constant-condition */）
• no-unreachable：检测 return 后面还有代码的死代码
• eqeqeq 强制使用 ===，避免 == 带来的隐式转换陷阱（如 0 == false 为 true）

如何让 ESLint 检出 undefined 访问导致的运行时错误

纯 JavaScript 下 ESLint 无法像 TypeScript 那样做完整类型流分析，但它能通过上下文线索捕获常见访问错误。关键在于启用并调优以下规则：

• no-undef：禁止使用未声明变量（但对属性访问无效）
• no-unused-expressions：拦截无副作用的表达式，比如 obj.prop; 单独一行（常是漏写赋值或函数调用）
• dot-notation + no-octal 等组合，间接减少因语法误解引发的访问异常
• 更有效的方式是配合 eslint-plugin-lodash-fp 或 eslint-plugin-sonarjs 中的 sonarjs/no-null-dereference 规则，它会对 obj?.prop?.method() 之外的链式访问（如 obj.prop.method()）在 obj 可能为 null/undefined 时告警

注意：sonarjs/no-null-dereference 依赖 JSDoc 类型标注或简单赋值推断（如 const obj = maybeNull(); if (obj) { obj.prop; } 可被放过），不是 100% 覆盖，但比默认规则强得多。

团队落地时最常被忽略的三个配置细节

规则开了 ≠ 生效了。很多团队配置完规则后仍频繁出现低级错误，问题往往出在配置链路断裂：

• 没关掉 env 中冗余环境：比如项目是 Node.js + Express，却保留了 browser: true，会导致 window、document 不报 no-undef，掩盖本该发现的客户端误用
• parserOptions.project 指向错误 tsconfig.json：TypeScript 项目若启用了 @typescript-eslint/restrict-template-expressions 等依赖类型信息的规则，但 project 路径不对或未包含当前文件，规则就静默失效
• 编辑器未正确读取 .eslintrc.cjs：VS Code 的 ESLint 插件默认只认 .eslintrc.js 或 .eslintrc.json；用 .cjs 扩展名时需在插件设置里显式指定 "eslint.options": { "configFile": "./.eslintrc.cjs" }

与 Prettier 冲突时，逻辑类规则优先保谁

当 ESLint 和 Prettier 都想管同一行（比如箭头函数单参数是否加括号），要明确：Prettier 只负责格式，ESLint 才管逻辑安全。所以冲突解决原则很直接：

• 删掉 prettier 插件里所有可能覆盖 ESLint 逻辑规则的配置，例如禁用 prettier/prettier 规则本身（它只是把 Prettier 错误转成 ESLint 报错），不要用它去覆盖 eqeqeq 或 no-cond-assign
• 用 eslint-config-prettier 关闭所有和格式相关的 ESLint 规则（如 indent、quotes），把格式权完全交给 Prettier；但所有带 no- 前缀的、涉及控制流/类型/作用域的规则，必须由 ESLint 独立保留并启用
• CI 流程中跑 eslint --ext .js,.jsx,.ts,.tsx src/ 即可，不用再跑 Prettier 检查——因为 eslint-config-prettier 已确保二者不打架，且逻辑规则不会被格式工具绕过

真正的防线不在“看起来整齐”，而在“根本写不出那种错”。只要 no-cond-assign 和 eqeqeq 在 CI 里硬性失败，开发者就只能改代码，而不是改缩进。

终于介绍完啦！小伙伴们，这篇关于《ESLint 强制代码规范，减少低级错误》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！