VS Code 的 linting 和格式化需按语言和项目显式配置工具链，否则仅启用内置简单规则；必须安装项目级依赖（如 eslint、prettier）、正确配置 .eslintrc.* 和 .prettierrc、启用 @typescript-eslint/parser 并指定 tsconfig.json 路径、避免规则冲突，并用 "editor.codeActionsOnSave": { "source.fixAll.eslint": true } 替代已废弃的 autoFixOnSave。
VS Code 的 linting 和格式化不是开箱即用的“一键开关”，必须按语言、按项目显式配置工具链，否则你看到的所谓“自动修复”大概率是 VS Code 自带的简单规则，和团队或工程实际要求完全脱节。
确认当前语言是否已安装对应 Linter 和 Formatter
比如写 TypeScript，eslint 和 prettier 都得是项目级依赖（devDependencies），不能只靠全局安装或 VS Code 插件“假装存在”。插件（如 ESLint 扩展）只是桥梁，真正执行的是你项目里 node_modules/.bin/eslint 这个二进制。
- 检查
package.json是否有"eslint"、"prettier"（或"@typescript-eslint/eslint-plugin"等） - 运行
npx eslint --version和npx prettier --version，确认能执行且版本兼容 - 如果用 Prettier 处理 TS，必须装
prettier-plugin-ts或升级到 Prettier 2.8+（原生支持）
配置 .eslintrc.* 和 .prettierrc 的位置与加载逻辑
ESLint 默认从当前工作目录向上查找最近的 .eslintrc.js（或 .eslintrc.cjs、.eslintrc.json），但 VS Code 的 ESLint 插件默认只监听打开的文件所在文件夹——如果你在多根工作区（multi-root workspace）中，每个文件夹需独立配 .eslintrc.*，否则 lint 规则不生效。
-
.prettierrc同理：它不会跨文件夹继承，prettier.config.js中的require()路径也以配置文件自身为基准，不是工作区根目录 - TS 项目务必在
eslint.config.js（或旧式.eslintrc.cjs）中启用@typescript-eslint/parser，且parserOptions.project指向正确的tsconfig.json路径，否则类型相关规则（如no-unused-vars）会误报 - 避免在
.eslintrc.*里写"extends": "prettier"却没装eslint-config-prettier——这会导致规则冲突，VS Code 可能静默跳过整个配置
VS Code 设置中关键项：不要全勾“format on save”
盲目开启 "editor.formatOnSave" 会让 Prettier 在保存时格式化，但它不等同于“先 lint 再 fix 再格式化”。ESLint 的自动修复（eslint --fix）和 Prettier 的格式化是两套机制，顺序错乱会导致代码反复被改写甚至破坏语义。
- 推荐关闭
"editor.formatOnSave"，改用"editor.codeActionsOnSave": { "source.fixAll.eslint": true } - 确保
"eslint.autoFixOnSave"已废弃（VS Code 1.8x+），必须用上面的codeActionsOnSave方式 - 如果项目同时用 ESLint + Prettier，应在
eslint.config.js中通过prettier/@typescript-eslint等组合配置统一入口，而不是让两个工具各自运行 - 某些场景（如 Markdown 中嵌入代码块）需要禁用特定语言的格式化：
"[markdown]": { "editor.formatOnSave": false }
最常被忽略的一点：VS Code 的“默认 formatter”设置（editor.defaultFormatter）只影响手动触发格式化的语言行为，不影响 codeActionsOnSave；而 ESLint 插件能否识别某个文件，取决于该文件的 languageId（比如 .tsx 是 typescriptreact，不是 typescript），配错 parser 或 extensions 就直接不 lint。
