ESLint --fix 不能自动修复逻辑错误，因为它仅支持格式类问题（如缩进、分号）和部分可推断的静态规则（如 no-unused-vars），而逻辑错误（如 if (x = 0)、for 循环条件错误）需语义分析，无法安全自动修正。
为什么 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 里硬性失败，开发者就只能改代码，而不是改缩进。
