eslint 更关键，因其专注代码逻辑错误检测（如未定义引用、条件恒真/假），而 prettier 仅负责格式美化（如缩进、引号），不检查语义正确性。
ESLint 是目前最直接、最可靠提升 JavaScript 代码逻辑严谨性的 VSCode 插件工具。它不是“锦上添花”的美化器，而是能揪出 undefined 引用、条件永远为真/假、变量重复声明、未使用的函数参数等真实逻辑漏洞的静态检查引擎。
为什么 ESLint 比 Prettier 更关键？
Prettier 只管“怎么写好看”，比如缩进几格、要不要分号；而 ESLint 管的是“有没有写错”，比如：
-
if (x = 5)（误用赋值而非比较）→ 被标记为no-cond-assign错误 for (let i = 0; i → 可能触发 <code>no-loop-func或被max-len规则间接暴露无限增长风险- 函数里写了
return却漏了后续分支的返回值 →consistent-return会报警
这些都不是格式问题，是运行时可能崩溃或行为异常的逻辑硬伤。
ESLint 配置中必须启用的核心规则
仅靠默认规则远远不够。以下几条直接影响逻辑健壮性，建议在 .eslintrc.js 中显式开启：
-
"no-unused-vars": ["error", { "argsIgnorePattern": "^_" }]—— 防止因变量未使用掩盖逻辑缺失（比如忘了处理回调的第二个参数） -
"no-unreachable": "error"—— 检测return、throw后面的死代码，常出现在早期if分支提前退出后 -
"eqeqeq": ["error", "always", { "null": "ignore" }]—— 强制严格相等，避免0 == false这类隐式转换导致的判断失准 -
"no-prototype-builtins": "error"—— 阻止直接调用obj.hasOwnProperty，防止原型链被污染后失效
注意：不要全局设 "no-console": "error"，调试时合理使用 console 是排查逻辑问题的重要手段。
和 Prettier 共存时最容易踩的坑
两者目标不同，但配置冲突会导致“检查报错却无法自动修复”或“格式化后反而触发新 lint 错误”。关键处理点：
- 必须安装
eslint-config-prettier并在extends中放在最后，它会关闭所有与 Prettier 冲突的规则（如quotes、semi） - VSCode 设置里禁用
"editor.formatOnSave"对 ESLint 的依赖，改用"editor.codeActionsOnSave": { "source.fixAll.eslint": true }—— 这样只执行 ESLint 自身支持的修复（如自动补全return），不干扰 Prettier 的格式化流程 - 如果项目用了 TypeScript，务必加
plugin:@typescript-eslint/recommended，否则any类型滥用、未声明属性访问等类型级逻辑漏洞不会被捕捉
ESLint 在编码当下就钉住，而不是靠人肉 Review 回溯。别跳过规则配置细节——一个没关掉的 no-unused-expressions 就可能让你错过三元表达式里本该执行的副作用调用。
