应将检查脚本放入项目目录并用 package.json 管理，配合 tasks.json 和 settings.json 统一配置，确保团队成员运行结果完全一致。
不能直接“共享脚本”——VSCode 本身不执行或分发你的检查脚本，它只负责调用、配置和展示结果。关键在如何让团队一致地运行同一套脚本，并复现相同输出。
把检查脚本放进项目目录并用 package.json 管理
这是最轻量、最可控的方式，避免依赖个人环境路径或全局安装。
- 将脚本（如
check-types.js、lint-staged.config.mjs）放在项目根目录或.scripts/子目录下 - 在
package.json的scripts字段中定义命令，例如："scripts": {<br> "check": "node .scripts/check-types.js",<br> "precommit": "npm run check"<br>} - 确保脚本使用相对路径读取源码（如
path.join(__dirname, "..", "src")），不硬编码/Users/xxx/... - 提交
package.json和脚本文件到 Git，新成员npm install && npm run check即可跑通
通过 VSCode 的 tasks.json 绑定快捷键触发
让团队成员不用记命令，按 Ctrl+Shift+P → “Tasks: Run Task” 就能执行检查，体验统一。
- 在项目
.vscode/tasks.json中添加 task，例如：{<br> "version": "2.0.0",<br> "tasks": [<br> {<br> "label": "Run type check",<br> "type": "shell",<br> "command": "npm run check",<br> "group": "build",<br> "presentation": { "echo": true, "reveal": "always" }<br> }<br> ]<br>} - 务必设
"group": "build"或"test"，这样可在状态栏快速触发（点击「▶️」图标） - 不要用
command直接写 Node 路径（如/usr/local/bin/node），而应走npm run—— 否则 Windows 用户会失败 - 该文件需提交进 Git，且建议在 README.md 中注明：“按 Ctrl+Shift+P → Tasks: Run Task → Run type check”
用 settings.json 配置 ESLint / TypeScript 插件自动调用
如果脚本本质是类型检查或代码规范（如基于 TypeScript 或 ESLint），别自己封装 CLI，直接配插件更稳定。
- 在项目
.vscode/settings.json中启用对应插件行为：{<br> "eslint.enable": true,<br> "eslint.run": "onType",<br> "typescript.preferences.includePackageJsonAutoImports": "auto"<br>} - 配合项目级配置文件（
tsconfig.json、.eslintrc.cjs）一起提交，VSCode 自动识别并加载 - 禁用用户级配置干扰：加
"eslint.useFlatConfig": true（ESLint v8.50+）或明确指定"eslint.options": { "configFile": "./.eslintrc.cjs" } - 注意：VSCode 的 ESLint 插件默认只检查打开的文件；如需全量扫描，仍需靠
tasks.json或终端命令
别踩这些坑
很多团队卡在这几步，不是脚本写得不对，而是分发和执行链断了。
-
node_modules/.bin不要硬编码进脚本路径——不同系统解析方式不同；一律用npx或npm run - 不要把检查脚本放在
%APPDATA%\Code\User\snippets\或其他 VSCode 用户目录里——那只是个人片段，不会被共享 - 避免用
require("D:/myproject/scripts/check.js")这类绝对路径；Node.js 的__dirname是唯一可靠的起点 - 如果脚本依赖特定 Node.js 版本（如只支持 v20+），在
engines字段声明，并配合.nvmrc或.tool-versions提示使用者
真正难的不是写脚本，而是让所有人运行时看到一模一样的错误位置、错误码和修复建议。路径、环境变量、Node 版本、插件版本，四个地方错一个，结果就不可复现。
