ESLint插件没反应，先检查项目根目录是否有.eslintrc.*配置文件、VSCode中eslint.enable是否为true、eslint.validate是否显式声明语言类型如["javascript","javascriptreact"]。
ESLint 插件没反应？先检查这三件事
VSCode 里装了 ESLint 插件但没报错、没提示，大概率不是插件坏了，而是配置链断在某个环节。最常卡在：项目根目录缺 .eslintrc.js 或 .eslintrc.json；VSCode 设置里没启用校验；或者文件类型没被识别为 JavaScript。
-
eslint.validate必须显式声明语言类型，比如["javascript", "javascriptreact"]，只写["javascript"]会导致 .jsx 文件不生效 - 如果项目用了 ESM（
type: "module"），.eslintrc.js需改成eslint.config.mjs，否则 ESLint 进程根本起不来 - VSCode 的
settings.json中若存在"eslint.enable": false，插件会彻底静默——这个开关比任何规则配置都优先
和 Prettier 冲突时，谁该让步？
Prettier 负责格式，ESLint 负责逻辑与风格规则，二者打架的典型表现是：保存后代码反复被改、光标乱跳、甚至出现“格式化失败”提示。根源在于规则重叠，比如 quotes、semi、comma-dangle 这些既在 ESLint 里定义，又被 Prettier 控制。
- 必须安装
eslint-config-prettier，并在extends数组末尾引入它，顺序不能错——它会关闭所有与 Prettier 冲突的 ESLint 规则 -
prettier插件本身不执行校验，只做格式化；真正触发校验的是 ESLint 插件，所以editor.defaultFormatter设为esbenp.prettier-vscode后，仍需靠 ESLint 提供诊断信息 - 不要在
.prettierrc里设"semi": true，同时又在 ESLint 里开"semi": ["error", "always"]，这种双写等于埋雷
JavaScript Booster 能自动重构，但别无脑点
这个插件的灯泡提示很诱人，但它的转换逻辑依赖 AST 分析，对作用域、副作用、模块导入导出等边界情况并不总是 100% 安全。比如把 function 转成箭头函数时，若原函数内用了 this 或 arguments，转换后行为会变。
- “Convert to const” 对
var a = 1; a = 2;这类明显重赋值的变量不会触发，这是正确行为；但若变量只在 if 块内赋值一次，插件可能误判为可转const - “Replace with ?:” 在嵌套条件或含异步调用的分支里可能漏掉副作用，比如
if (x) { log('yes'); return 'a'; } else { log('no'); return 'b'; }被压缩后，log调用顺序不变，但调试时更难打断点 - 它不修改 import/export 语句，也不处理 TypeScript 类型注解，纯 JS 项目可用性高，TS 项目里部分选项会灰掉
规则配置写在哪儿，优先级真不一样
同一项规则（比如 no-console）出现在不同位置，效果可能完全不同。VSCode 不是简单合并配置，而是按路径层级和加载顺序覆盖。
- 最高优：工作区级
.vscode/settings.json里的eslint.options或eslint.run，能强制指定配置文件路径，绕过自动查找 - 中高优：
.eslintrc.js是项目级规则主体，但若用了extends: ["airbnb"]，Airbnb 规则里的no-console就可能被你本地的"no-console": "off"覆盖，顺序很重要 - 最低优：全局 VSCode 设置里的
eslint.packageManager或eslint.nodePath，只影响插件启动方式，不参与规则判定
实际项目里，.eslintrc.js 和 .prettierrc 必须共存且明确分工，而 .vscode/settings.json 只该放编辑器行为控制项（如 formatOnSave），别往里塞规则定义——那会让新成员 clone 项目后第一秒就踩坑。
