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 中显式开启：

Wjs Uploading Video

将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。

下载

• "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 类型滥用、未声明属性访问等类型级逻辑漏洞不会被捕捉

真正影响 JS 逻辑严谨性的，从来不是语法糖写得多炫，而是变量生命周期是否清晰、分支覆盖是否完整、副作用是否可控。这些都得靠 ESLint 在编码当下就钉住，而不是靠人肉 Review 回溯。别跳过规则配置细节——一个没关掉的 no-unused-expressions 就可能让你错过三元表达式里本该执行的副作用调用。