eslint扩展通过lsp协议触发静态分析，依赖项目本地eslint包和配置文件（如eslint.config.js），将保存等事件转发给cli执行规则校验，并将诊断结果推送至ui显示。
ESLint 扩展如何触发静态分析
VSCode 里的 ESLint 不是独立运行的，它依赖项目中已安装的 eslint 包和配置文件。插件本身只负责把编辑器事件（比如保存）转给本地 ESLint CLI，再把诊断结果通过 LSP 推给 UI。没装包、没配文件，插件就完全不干活。
- 必须在项目根目录运行
npm install eslint --save-dev或yarn add eslint -D - 必须存在
.eslintrc.js、.eslintrc.cjs或eslint.config.js（新版推荐后者） - 如果用
eslint.config.js，注意导出格式要符合import('eslint').Linter.Config类型，否则 VSCode 会静默失败 - 插件默认只校验
javascript和typescript，若需检查.vue或.jsx，得在设置里显式加进eslint.validate数组
为什么保存后没自动修复
“保存即修复”不是默认开启的，且容易被覆盖。常见失效原因是配置层级冲突：用户设置、工作区设置、项目内 .vscode/settings.json 三者优先级不同，低优先级的会被高优先级覆盖。
- 确认启用的是
"editor.codeActionsOnSave": { "source.fixAll.eslint": true }，不是"source.fixAll"（后者会触发所有修复器，包括 Prettier，可能冲突） - 如果同时开了
editor.formatOnSave，且 formatter 设为 Prettier，两者可能打架——建议关掉formatOnSave，只留 ESLint 的fixAll - 某些规则不可自动修复（如
no-console），它们只报 warn/error，不会出现在修复列表里 - 文件编码不是 UTF-8、或含有 BOM 头时，ESLint 可能解析失败，导致无响应
Error Lens 怎么增强 ESLint 提示
Error Lens 不替代 ESLint，而是把 ESLint（及其他语言服务器）输出的诊断信息，从底部面板/侧边图标搬到代码行内，让错误更“贴着上下文”。它不改分析逻辑，只改展示方式。
- 安装后默认启用，但需确保 ESLint 扩展已在运行——Error Lens 本身不带分析能力
- 若行尾没显示提示，先看 VSCode 底部状态栏有没有 ESLint 图标亮起；没亮说明 ESLint 没加载成功
-
errorLens.messageMode设为inline时，提示紧贴代码右侧；设为hover则只悬停显示，适合避免行宽溢出 - 可配合
errorLens.ignoreRules屏蔽干扰项，比如["no-console"]，避免满屏黄色警告掩盖真正问题
jsconfig.json 对静态分析的影响
jsconfig.json 不是 ESLint 配置，但它影响 VSCode 内置的 JavaScript 语言服务——也就是类型推断、跳转、重命名这些基础能力。ESLint 不读它，但 IntelliSense 会。
- 必须含
"checkJs": true，否则 JSDoc 注释、@type标注全无效，智能提示退化为纯字符串匹配 -
"include"字段漏写**/*.js，会导致部分文件被排除在类型检查之外，JSDoc 失效 - 若项目用 ESM（
type: "module"），但jsconfig.json里没设"compilerOptions.module": "ESNext"，模块解析可能出错，import 提示不准 - 和 ESLint 规则无关，但会影响
no-unused-vars这类规则的实际效果——因为变量是否“被使用”，依赖语言服务对引用关系的判断
