VS Code本身不共享脚本，真正可复用的是package.json的scripts字段与tasks.json定义的任务；二者结合显式声明执行上下文（如npx、${workspaceFolder}），才能确保跨机器、跨人员一致运行。
VSCode 本身不“共享”脚本，只共享配置；真正能被团队复用、跨机器稳定执行的，是 package.json 中定义的 scripts + 显式声明的执行上下文（比如 tasks.json 或终端命令），而不是靠个人终端 PATH 或插件右键菜单。
package.json 的 scripts 是唯一可移植的“运行脚本”载体
VSCode 没有内置“共享脚本”功能，但 package.json 的 scripts 字段是前端/Node 工程事实标准。只要写进这个字段，任何人在该目录下运行 npm run xxx 就能触发相同逻辑——前提是依赖已安装、命令在 $PATH 中可用。
- 别把脚本逻辑写进 VSCode 插件配置（如 Code Runner 的
executorMap），它不会随项目提交，别人 clone 后无效 - 避免硬编码绝对路径，例如
"build": "node /Users/xxx/scripts/build.js"—— 改成相对路径"build": "node scripts/build.js" - 如果脚本依赖全局工具（如
prettier），要么加npm install --save-dev prettier后用npx prettier，要么在scripts里显式调用./node_modules/.bin/prettier - Windows 用户注意：
scripts中的 shell 语法（如&&、||）在 Windows CMD 下行为不同，建议统一用cross-env或改用npm-run-all管理流程
tasks.json 才是 VSCode 内部可共享的“一键运行”机制
想让同事按 Ctrl+Shift+P → Tasks: Run Task 就跑起来，必须把逻辑放进项目根目录的 .vscode/tasks.json。它比右键“Run Code”或插件配置更可靠，因为会被 Git 跟踪、可审查、可调试。
-
tasks.json里的command推荐用npm run xxx或npx xxx，而不是直接写node script.js——这样能复用package.json的环境和版本控制 - 务必设
"group": "build"或"problemMatcher"，否则任务无法归类，错误也不会高亮到编辑器中 - 不要在
args里拼接用户路径变量（如$HOME），改用${workspaceFolder}或${file}这类 VSCode 内置变量 - 如果脚本需要读取
.env文件，tasks.json不会自动加载，得在command前加dotenv run --或改用cross-env注入
为什么“右键 Run Code”不能共享？
Code Runner 插件的执行逻辑默认存在三处不可移植性：它用 /bin/sh -c 执行 .sh 文件、不加载用户 shell 配置（~/.zshrc）、且 executorMap 设置保存在用户级而非工作区级设置中。
- 你改了自己电脑上的
code-runner.executorMap，别人 clone 项目后完全感知不到 - 报错
command not found: declare或Permission denied，90% 是因为 Code Runner 用/bin/sh解释了 Bash 语法，或文件没chmod +x - 解决方案不是教每个人去改设置，而是统一用
tasks.json定义："command": "bash", "args": ["${file}"]，并确保脚本首行是#!/usr/bin/env bash - 如果脚本依赖
alias或函数，tasks.json也不自动 source，得显式加"args": ["-c", "source ~/.zshrc && bash ${file}"]（不推荐，应把逻辑移进脚本内）
真正的共享难点不在“怎么点一下就跑”，而在于“怎么让所有人跑出一致结果”——这取决于是否把环境假设（Node 版本、shell 类型、权限、env 变量）全部显式声明在 package.json 和 .vscode/tasks.json 里，而不是藏在某个人的终端配置中。
