ESLint最严格源于可定制的parser与插件链：默认配置宽松，需手动配置@babel/eslint-parser等解析器支持现代语法，并通过extends引入eslint:recommended、plugin:react、plugin:import等插件组合规则，VSCode需对齐本地版本并使用CommonJS格式配置文件。
ESLint 是目前 VSCode 中 JavaScript 代码检查最严格、可定制性最强的选择，但它“严格”不来自开箱即用，而取决于你如何配 parser、extends 和 rules —— 默认配置其实很宽松。
为什么 ESLint 能做到最严格？关键在 parser 和插件链
ESLint 本身只做规则校验，真正决定“能不能解析 JSX/TS/Top-level await”的是 parser。默认用 @babel/eslint-parser 或 @typescript-eslint/parser 才能覆盖现代语法；否则遇到 const Foo = () => <div></div> 就直接报 Parse error: Unexpected token，连规则都不跑。
严格性还来自插件组合：
-
eslint:recommended只开 20 条基础规则（如no-unused-vars），远不够 - 加
plugin:react/recommended+plugin:react-hooks/recommended才会检查useEffect依赖项 - 加
plugin:jsx-a11y/recommended才校验无障碍属性（alt缺失、role拼错） - 加
plugin:import/recommended才报import/no-unresolved或循环引用
这些不是“开关”，是独立 npm 包，必须显式安装并写进 extends 数组里。
VSCode 不报错但命令行 eslint 正常？90% 是没走本地版本
VSCode 默认找全局 eslint，而项目里装的是 node_modules/.bin/eslint —— 两者版本、插件、解析器路径全不同。典型表现：右下角 ESLint 图标显示 Using globally installed ESLint。
必须手动对齐：
- 在工作区
.vscode/settings.json里加："eslint.packageManager": "npm"（或"pnpm"，和你项目一致） - 确认根目录有
package.json且已运行npm install - 删掉
eslint.nodePath字段（它已被弃用，新版插件不认） - 重启窗口，或执行
Developer: Reload Window
别信“已安装插件就自动生效”——VSCode 的 ESLint 扩展不会主动扫描 node_modules，它只按设置去调用可执行文件。
.eslintrc.js 里 module.exports = {} 和 export default 都不行？
VSCode 的 ESLint 插件（截至 2026 年 5 月）仍基于 Node.js 的 CommonJS 加载机制，export default 是 ESM 语法，直接报 Cannot use import statement outside a module。
正确写法只有两种：
-
module.exports = { rules: { 'no-console': 'warn' } }（.eslintrc.js） -
module.exports = { ...require('@rushstack/eslint-patch/modern-module-resolution') }（需额外 patch 才支持 modern import）
如果用了 eslint.config.js（ESLint v8.22+ 新格式），必须在设置里显式指定："eslint.options": { "configFile": "./eslint.config.js" }，否则插件直接跳过。
保存时 auto-fix 把代码改崩了？别开 source.fixAll
"editor.codeActionsOnSave": { "source.fixAll.eslint": true } 看似方便，实则危险：它会触发所有注册的修复器，包括 Prettier（如果你装了 Prettier 扩展）、TypeScript 的自动导入、甚至某些插件的重命名逻辑。
更安全的做法是只放 ESLint 自己能 fix 的规则：
- 用
"source.fixAll.eslint": true（确保其他扩展没注册同名 action） - 或更细粒度：
"source.fixAll.eslint": ["semi", "quotes", "no-trailing-spaces"] - 绝对不要开
"source.fixAll": true—— 它会混入非 ESLint 的修复器，顺序不可控
React 项目里尤其明显：source.fixAll 可能强行加 import React from 'react' 到 .js 文件，而你的 Babel config 明确关掉了自动注入。
最易被忽略的一点：ESLint 的严格性永远受限于 parser 能否成功解析。JSX 报错、TS 类型不提示、import.meta.env 标红……八成不是规则没开，而是 parserOptions.project 没指向 tsconfig.json，或 ecmaVersion 还卡在 2018。
