VSCode必装核心插件是EditorConfig for VS Code、Prettier与ESLint，三者构成代码风格闭环：EditorConfig统一底层格式（缩进、换行符等），Prettier负责多语言自动格式化，ESLint实时检查JS/TS逻辑错误与规范，需通过eslint-config-prettier禁用冲突规则并配置formatOnSave与defaultFormatter。
VSCode 本身不是“最强开发神器”，真正让它变强的，是插件组合——但盲目装一堆插件反而拖慢启动、引发冲突、掩盖真实问题。关键不是“最多”，而是“刚好够用 + 稳定可维护”。
哪些插件属于必装且低风险的核心层
核心插件必须满足：有持续维护（近 3 个月内有 commit）、无全局 monkey patch、不强制改 VSCode 默认键位。实际项目中，EditorConfig for VS Code、Prettier、ESLint 这三个构成代码风格闭环，但要注意顺序和冲突点：
-
ESLint和Prettier同时启用时，必须关掉Prettier的 auto-format-on-save，否则会覆盖 ESLint 的修复逻辑 -
EditorConfig的.editorconfig文件里不能写indent_style = tab后又让Prettier强制用空格，否则保存时反复切换缩进 - TypeScript 项目优先用
ESLint+@typescript-eslint规则，别装TSLint（已废弃，VSCode 可能仍搜到旧版）
调试类插件怎么选才不踩 runtime 坑
调试体验差，往往不是插件没装，而是底层运行时没对齐。比如装了 Python Debugger 却用 conda 环境没激活，或 Remote - SSH 连上服务器后没在远端安装 vscode-server，都会报 Cannot resolve the provided debug type "python" 这类错误。
- Node.js 调试直接用内置
Node Debug（VSCode 1.80+ 已集成），不用额外装Debugger for Chrome或旧版Node.js Extension Pack - Go 项目务必确认
go命令在 PATH 中可用，且GOROOT和GOPATH没被插件配置覆盖（Go插件设置项里有个"go.goroot"容易误填绝对路径） - 使用
Remote - Containers时，Dockerfile 里必须显式安装git和curl，否则插件拉取 devcontainer.json 依赖会静默失败
性能敏感场景下哪些插件该禁用或替换
打开 5w 行日志文件或大型 monorepo 时，GitLens、Bracket Pair Colorizer、Auto Rename Tag 是最常触发卡顿的三类。它们不是“不好”，而是设计上就依赖高频 AST 解析或 DOM 遍历。
-
GitLens建议关闭gitlens.advanced.blame.ignoreWhitespace和gitlens.codeLens.enabled，保留行内 blame 即可 - 括号高亮现在应优先用 VSCode 内置的
"editor.matchBrackets": "always"，而非第三方插件 -
Auto Rename Tag和原生"editor.renameOnType": true功能重叠，React/Vue 项目中后者更稳，前者在 JSX 中偶发漏 rename
真正难的不是找插件，是判断某个功能到底该由插件实现，还是该靠语言服务、脚本或 CI 流程承接。比如“提交前检查 ESLint 错误”，用插件做提示不如用 husky + lint-staged，既不拖 VSCode，又保证所有协作者行为一致。
