VSCode插件本身不直接实现CI，仅负责本地开发阶段的代码质量加固和流程衔接；真正的CI必须由Git仓库触发，在独立服务器或云服务（如GitHub Actions）中运行，插件作用是让本地代码“更接近CI要求”，避免提交后被流水线卡住。
VSCode 插件本身不直接实现持续集成（CI），它只负责本地开发阶段的代码质量加固和流程衔接。真正的 CI 必须由 Git 仓库触发、在独立服务器或云服务（如 GitHub Actions、GitLab CI、CircleCI）中运行。插件的作用是让本地代码“更接近 CI 要求”，避免提交后被流水线卡住。
为什么 ESLint + Prettier 插件是 CI 前置门槛
CI 流水线通常包含 eslint --fix 和 prettier --write 步骤。如果本地没配好对应插件，你可能：
- 提交前没发现 no-unused-vars 报错，CI 直接 fail
- 手动格式化风格和 CI 自动格式化冲突，导致 diff 混乱
- 依赖 eslint-plugin-vue 或 @typescript-eslint 的规则，但插件未启用，本地无提示
- 必须确保 VSCode 中的
ESLint扩展已启用，且项目根目录存在.eslintrc.js或.eslintrc.cjs -
Prettier扩展需设为默认格式化工具，并在settings.json中配置："editor.formatOnSave": true - 若项目用 TypeScript，
parser必须设为@typescript-eslint/parser，否则interface或泛型会报错
如何让插件行为和 CI 完全一致
本地插件只是“镜像”CI 环境，不是替代品。一致性取决于三处对齐：
-
package.json中的 lint 脚本（如"lint": "eslint . --ext .js,.ts"）要和插件实际扫描路径一致；否则插件可能漏检src/utils/下的文件 -
.eslintignore和 VSCode 的eslint.options.cwd配置必须匹配，否则插件会在 node_modules 里报一堆误报 - CI 使用的 Node.js 版本（如 v20.15）应与本地一致；高版本 ESLint（v9+）在低版本 Node 下可能无法加载
flat config格式
Git Hook 插件（如 Husky + lint-staged）不是可选项
仅靠编辑器插件无法拦截错误提交。必须搭配本地 Git 钩子，否则团队成员仍可能绕过检查直接 push。
- 安装
husky后，pre-commit钩子会调用lint-staged，只检查暂存区文件——这比全量eslint .快 5–10 倍 -
lint-staged配置中指定的命令（如eslint --fix）必须与 CI 中执行的命令完全一致，包括参数和路径 - VSCode 插件不参与钩子执行，但它能提前暴露问题：如果插件已标红某行，
git commit时lint-staged几乎必然失败
真正容易被忽略的是：插件只校验打开的文件，而 CI 校验所有匹配文件。一个没打开的 legacy.js 文件可能长期带 var 声明，插件从不提醒，直到 CI 报错才暴露。所以定期手动跑一次 npx eslint . 仍是必要动作。
