必须固定Prettier为默认格式化器，并通过"source.fixAll.eslint": true显式启用ESLint自动修复，二者职责分离：Prettier统一代码样式，ESLint校验逻辑与规范，避免因多格式器冲突导致分号、引号等风格混乱。
ESLint 和 Prettier 必须共存，但不能都设为默认格式化器
VSCode 里同时装了 ESLint 和 Prettier 插件，却只靠 "editor.formatOnSave": true 触发格式化，结果代码风格混乱、分号时有时无——根本原因是两个工具职责不同，且 VSCode 只允许一个默认格式化器。
-
Prettier负责统一代码外观（缩进、换行、引号、括号位置），它不关心逻辑错误 -
ESLint负责语义和规范校验（no-unused-vars、no-console、semi），部分规则支持自动修复 - 若把
Prettier设为默认格式化器，又没配"source.fixAll.eslint"，ESLint 的可修复规则（比如semi）就永远不会生效 - 反过来，若把 ESLint 设为默认格式化器，Prettier 的排版能力会被绕过，导致样式不一致
正确做法是：固定 Prettier 为 editor.defaultFormatter，再通过 editor.codeActionsOnSave 显式启用 ESLint 自动修复：
{
"editor.formatOnSave": true,
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true
}
}
ESLint 配置文件必须放在项目根目录，且优先级高于全局设置
你在用户设置里写了 "eslint.validate": ["javascript"]，但打开项目后 ESLint 标红没反应——大概率是项目里缺 .eslintrc.js 或 .eslintrc.json，或者它不在根目录。
- VSCode 的 ESLint 扩展默认只读取项目根目录下的配置文件；子文件夹里的
.eslintrc不会被识别 - 配置优先级严格遵循：项目根目录配置 > VSCode 工作区设置 > 用户全局设置
- 如果项目用了
eslint-config-prettier，必须在extends数组里把它放在最后，否则会覆盖掉 Prettier 的禁用规则 -
parserOptions.ecmaVersion建议显式设为2022或更高，避免遇到??=、at()等新语法时报错
DeepSeek 插件与 ESLint 冲突时，错误提示会互相掩盖
开启 DeepSeek 的 Inline Suggestions 后，ESLint 的下划线警告变淡、甚至消失；或者 DeepSeek 推荐的代码补全被 ESLint 标红——这不是 bug，是两个插件对同一段 AST 的不同解读造成的视觉干扰。
- DeepSeek 的补全建议默认不经过 ESLint 校验，它按“语法合法+上下文合理”生成，可能违反团队规则（比如漏分号、用
var） - ESLint 的实时诊断发生在编辑器解析阶段，而 DeepSeek 的建议插入在光标处，两者触发时机不同步
- 临时缓解：在写关键逻辑前手动运行
eslint --fix，或关闭 DeepSeek 的deepseek.enableCodeActions - 长期解法：用
eslint-plugin-deepseek（需自行维护）把 DeepSeek 输出纳入 ESLint pipeline，但目前无官方支持
保存时自动修复有边界，别指望它解决所有问题
"source.fixAll.eslint": true 看起来很省心，但实际只能修复约 30% 的 ESLint 规则，比如 semi、quotes、indent 这类纯样式规则；而 no-console、no-unused-vars、complexity 这些逻辑类规则，ESLint 默认不提供自动修复入口。
- 检查你的
.eslintrc里每条规则的第三项是否为"fixable"：比如"semi": ["error", "always"]是可修复的，但"no-console": "warn"不是 - 某些规则（如
react-hooks/exhaustive-deps）虽标为 fixable，但修复结果未必符合业务意图，需人工核对 - 如果保存后没变化，先确认当前文件是否被 ESLint 识别：右下角状态栏应显示
ESLint: enabled，否则可能是文件后缀不匹配或eslint.validate没包含该语言
真正难的是规则设计本身——比如要不要禁用 any 类型、函数参数是否强制命名，这些没法靠插件自动决定。集成越深，越得花时间对齐团队认知。
