VS Code 静态检查需扩展+外部工具协同，关键在选对扩展、配好语言服务器、确认CLI已安装（如eslint需npm install）、正确配置解析器与作用域，否则易静默失败。
VS Code 本身不自带静态检查能力，必须通过扩展和外部工具协同实现。关键在于选对扩展、配好语言服务器、理解检查时机——不是装了插件就自动报错，很多问题要保存文件或手动触发才出现。
安装 ESLint / Prettier / SonarLint 等对应语言的检查扩展
不同语言用的工具完全不同：JavaScript/TypeScript 主靠 ESLint（需本地或全局安装 eslint 包），Python 用 pylint 或 pyright，Go 用 gopls 内置支持，Rust 依赖 rust-analyzer。别只装 VS Code 插件却不装底层 CLI 工具——比如只装 ESLint 扩展但没运行 npm install eslint --save-dev，插件会直接提示 “Cannot find module ‘eslint’”。
- JavaScript 项目优先用
ESLint+eslint-config-airbnb或eslint-config-prettier关闭冲突规则 - TypeScript 项目务必启用
parserOptions.project指向tsconfig.json，否则类型相关规则（如no-unused-vars）会误报 - 避免同时启用
ESLint和TSLint（已废弃），后者在 VS Code 中仍可能残留配置导致冲突
配置 settings.json 控制检查行为
默认设置下，ESLint 只校验 .js 和 .jsx 文件，.ts 和 .tsx 需手动加入 eslint.validate 数组；Prettier 默认不参与“错误级”检查，只做格式化——想让它报错（比如单引号 vs 双引号），得配合 ESLint 的 eslint-config-prettier 和 eslint-plugin-prettier。
- 开启保存时自动修复：
"editor.codeActionsOnSave": { "source.fixAll.eslint": true } - 禁用特定文件夹检查（如
node_modules或生成代码）："eslint.options": { "ignorePath": ".eslintignore" } - 区分开发与 CI：本地可关掉耗性能的规则（如
complexity），CI 流水线里再打开
识别常见误报与静默失败场景
静态检查“没反应”比报错更难排查。典型静默失败包括：工作区根目录没找到 eslint.config.js 或 .eslintrc.cjs；当前打开的文件不属于任何已配置的 eslint.workingDirectories；Node.js 版本太低导致 ESM 配置加载失败（报错 Must use import to load ES Module）。
- 右下角状态栏点击
ESLint图标可查看当前文件是否被监听、用了哪个配置、有无解析错误 - 按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），输入ESLint: Show Output查看详细日志 -
import路径别名（如@/utils）未在compilerOptions.baseUrl和paths中声明，会导致no-unresolved误报
真正卡住人的往往不是“怎么开检查”，而是“为什么这行明显有问题却没标红”。多看输出面板、确认配置作用域、检查 Node.js 和工具版本兼容性——这些地方不花时间验证，装十款插件也没用。
