vscode需扩展与外部工具协同实现代码检查；须按语言选配兼容lsp和格式化器，正确配置settings.json禁用冲突选项，并确保项目级配置文件完备且path环境正常。
VSCode 本身不内置代码检查，得靠扩展 + 外部工具协同工作；配置错顺序或忽略语言服务器兼容性，eslint、pylint、prettier 很容易互相打架，报错却没提示、保存不自动修复是常态。
装对扩展：按语言选 LSP + 格式化器
不同语言依赖不同的语言服务器协议（LSP）实现诊断能力，不能只装一个“万能插件”：
-
Python：必须装Python官方扩展（含 Pylance），再单独配pylint或flake8——pylsp和pyright不能混用，否则类型检查和错误高亮会冲突 -
JavaScript/TypeScript：优先用内置的typescript-language-server，额外加ESLint扩展（不是eslint-plugin那类辅助插件），禁用TSLint（已废弃） -
Go：只启用gopls，别装旧版go-outline或go-imports，它们和 VSCode 1.80+ 的模块管理不兼容
配置 settings.json：关掉自动格式化陷阱
很多人开 "editor.formatOnSave": true 后发现代码越改越乱，问题常出在格式化器和 linter 职责重叠：
- 禁用编辑器默认格式化：
"editor.formatOnSave": false，把控制权交给prettier或语言专属工具 - 让 ESLint 管修复：
"eslint.enable": true+"eslint.codeAction.showDocumentation": true，配合快捷键Ctrl+Shift+P→ESLint: Fix all auto-fixable Problems - 若坚持保存即格式化，必须指定格式化器：
"editor.defaultFormatter": "esbenp.prettier-vscode"，且确保项目根目录有.prettierrc，否则 prettier 按默认规则跑，和 ESLint 规则对不上
项目级配置文件不能少：避免全局配置污染
全局设置看着省事，但团队协作时极易引发风格冲突。每个项目必须带自己的配置文件：
-
package.json中的eslintConfig字段优先级低于.eslintrc.js，建议统一用.eslintrc.cjs（支持import语法且兼容 Node.js 14+） -
pyproject.toml是 Python 项目的事实标准，[tool.pylint]和[tool.black]要分开写，别试图用pylint做格式化 - 没有
tsconfig.json的 TS 项目，typescript-language-server会退化为 JS 模式，类型检查直接失效
最常被跳过的一步：确认 node_modules/.bin 或 venv/Scripts 在 VSCode 终端 PATH 里——扩展调用 CLI 工具失败时，不会弹错误框，只会静默禁用检查功能。
