VSCode插件本身不参与CI构建或测试执行，真正关键的是插件所依赖的CLI工具链（如eslint、prettier、tsc）及其配置文件（.eslintrc.cjs、tsconfig.json等）必须与CI脚本完全一致并提交至Git；vscode/settings.json需禁用绝对路径和纯UI设置；扩展应通过code --install-extension配合extensions.list管理；problemMatcher须使用标准模式以统一本地与CI的错误解析。
团队 CI 流程中，VSCode 插件本身不参与构建或测试执行，但插件配置直接影响本地开发行为与 CI 的一致性。真正该管的不是“插件安装”，而是插件所依赖的工具链、格式化规则、类型检查逻辑是否与 CI 对齐——否则装再多插件也没用。
vscode 插件不进 CI，但它的配置必须进版本控制
VSCode 插件（如 ESLint、Prettier、TypeScript）只是前端界面层，实际工作由 CLI 工具完成：eslint、prettier、tsc 等命令才是 CI 中真正运行的部分。插件只是调用它们并把结果渲染到编辑器里。
- 所有插件相关的配置（如
.eslintrc.cjs、prettier.config.js、tsconfig.json）必须提交到 Git，且与 CI 脚本中使用的参数完全一致 -
.vscode/settings.json可以存，但要禁用任何“仅本地生效”的路径或绝对路径（如"eslint.runtime": "/usr/local/bin/node"） - 避免在
settings.json里写"editor.formatOnSave": true这类纯 UI 行为；它不该影响 CI，但如果团队靠它“假装格式正确”，反而掩盖了prettier --check在 CI 中的真实失败
批量安装 .vsix 不适合 CI 场景，该用 code --install-extension + 清单文件
CI 环境不需要图形界面，也不该依赖 `.vsix` 文件手动分发。真正可控、可审计、可复现的方式是：用 code --install-extension 命令配合扩展 ID 列表。
- 维护一个
.vscode/extensions.list文本文件，每行一个官方扩展 ID，例如：esbenp.prettier-vscodedbaeumer.vscode-eslint - 在 CI 构建前（或 DevContainer 初始化时），用脚本批量安装：
cat .vscode/extensions.list | xargs -I {} code --install-extension {} --force - 注意：GitHub Actions 默认不带 VSCode CLI；若需在 runner 上模拟编辑器环境（如做 UI 层 lint 验证），应改用 DevContainer 或直接在本地 pre-commit 阶段验证，而非塞进 CI
problemMatcher 是连接本地任务和 CI 日志的关键桥梁
VSCode 的 problemMatcher 字段不是装饰品。它把终端输出解析成结构化错误，让“本地跑 test 失败”和“CI 报错行号不一致”这类问题归零。
- 必须使用标准 matcher，比如：
$tsc、$eslint-stylish、$jest-webpack，而不是自定义正则——除非你愿意为每个 CI 日志格式单独维护一套 - 确保你的 CI 脚本也启用相同 reporter：例如 Jest 加
--json --outputFile=jest-results.json，再配"problemMatcher": ["$jest-junit"]，这样本地和 CI 都能点错误跳转到源码 - 常见坑：
npm run test包了一层 shell 脚本后，原始 stderr 被吞掉，导致 problemMatcher 失效；建议在tasks.json中直接调用 CLI（如jest）而非 npm script 别名
最易被忽略的一点：插件管理的终点不是“所有人装了什么”，而是“所有人执行了什么命令、用了什么配置、输出了什么结构”。只要这三者对齐，VSCode 是不是最新版、有没有装 Remote-SSH，都不影响 CI 结果可信度。
