vscode插件真正落地标准化需配置文件与插件行为协同：必须在settings.json中明确指定editor.defaultformatter、formatonsave、codeactionsonsave，配合项目级.eslintrc.js和.prettierrc，并安装eslint-config-prettier解耦冲突规则，同时验证语言模式和命令行依赖是否就绪。
VSCode插件如何真正落地标准化，而不是只装不生效
装了 Prettier、ESLint、Volar 就算标准化？不是。很多团队配置完发现：有人格式化后代码变样、有人保存没反应、有人提交的代码仍被 CI 拒绝——问题不在插件本身，而在插件和项目配置的协同逻辑没对齐。
关键点在于：VSCode 插件只是执行器，真正决定“怎么格式”“何时检查”“用哪套规则”的，是项目里的配置文件 + 插件行为开关的组合。插件装了但没配对，等于买了扳手却没拧对螺栓。
-
settings.json里必须明确指定"editor.defaultFormatter"，否则即使装了 Prettier，VSCode 也可能调用内置 JavaScript 格式器（尤其在 .ts 文件中） -
extensions.json中的"recommendations"是提示，不是强制；若要确保统一，需配合文档说明或 pre-commit 钩子兜底 - 插件启用后，仍需验证其是否实际接管了对应语言模式：右下角语言标识必须是
Vue或TypeScript，而非Plain Text或JavaScript，否则 Volar / ESLint 插件根本不会响应
.vscode/settings.json 里哪些字段直接影响标准化效果
这个文件是项目级设置的中枢，但很多人只改 formatOnSave，忽略了几个隐性开关，导致“看起来开了自动格式，实际没走 Prettier”。
-
"editor.formatOnSave": true是基础，但必须搭配"editor.defaultFormatter": "esbenp.prettier-vscode"才生效；否则可能 fallback 到 VSCode 自带格式器 -
"editor.codeActionsOnSave": { "source.fixAll": true }这个开关能让 ESLint 在保存时自动修复可修问题（如no-unused-vars），但前提是eslint.enable为true且项目里有有效.eslintrc.js -
"files.eol": "\n"强制 LF 换行符，避免 Windows 用户提交 CRLF 导致 Git diff 炸锅；"editor.insertSpaces": true和"editor.tabSize": 2必须成对出现，否则缩进行为不可控
Prettier 和 ESLint 规则冲突时，谁该让步
常见现象：prettier 要求单引号，eslint 报错“字符串必须用双引号”，保存后反复来回改。这不是 bug，是规则重叠未解耦。
- 优先让 ESLint 让步：安装
eslint-config-prettier并在.eslintrc.js的extends数组末尾加入它，它会关闭所有与 Prettier 冲突的格式类规则（如quotes、semi） -
.prettierrc里只保留纯格式项（singleQuote、tabWidth、trailingComma），语义类规则（如no-console、no-var）全交给 ESLint 管理 - 验证方式：运行
npx eslint --fix src/后再手动保存一个文件，观察是否还有格式抖动；若有，说明eslint-config-prettier没正确加载或版本不匹配
为什么 Doxygen 注释生成插件总静默失败
不是插件坏了，而是它根本不干活——它只写模板，真正生成注释依赖本地 doxygen 命令行工具。跳过这步，插件连 @param 都推不出来。
- 先在终端运行
doxygen -v，必须返回版本号（如1.9.8）；若报command not found，说明 PATH 没配好，插件必然失效 - macOS 用
brew install doxygen，Windows 安装时务必勾选Add doxygen to PATH，Linux 用sudo apt install doxygen - 插件触发前，光标必须落在函数声明正上方的空行；且当前文件语言模式必须是
C++或Python（右下角显示），否则插件直接忽略
标准化最难的部分不是配多少文件，而是让每个成员的 VSCode 实际执行同一套逻辑。路径、权限、语言模式、命令行依赖——任一环节断链，配置就变成摆设。
