tasks.json与.github/workflows/是同一逻辑在不同环境的复用载体，一致性需人工对齐命令、路径、环境变量等；根本差异在于执行上下文——本地默认工作目录为workspace root，ci需显式指定working-directory，且env不互通、problemmatcher仅作用于本地错误定位。
tasks.json 和 .github/workflows/ 不是“配对工具”，而是同一套逻辑在不同执行环境的复用载体。一致性不是自动发生的，得靠人对齐命令、参数、路径、环境变量和错误处理方式。
为什么本地 npm run build 成功，GitHub Actions 却报 Module not found
根本原因常是路径或工作目录不一致：tasks.json 默认在 VSCode 打开的根目录执行，而 GitHub Actions 的 actions/checkout@v3 默认检出到 /home/runner/work/repo-name/repo-name，但如果你的 package.json 不在仓库根目录（比如在 packages/frontend），本地命令能跑通，CI 就会因找不到 node_modules 或入口文件失败。
- 检查
tasks.json中"cwd"字段是否显式指定，没写就默认用 workspace root；CI 里必须用working-directory显式声明，例如：steps:<br> - uses: actions/checkout@v3<br> - name: Install and build<br> working-directory: ./packages/frontend<br> run: npm ci && npm run build
- 避免在
tasks.json里写相对路径如../scripts/build.js，CI 环境没有你本地的父级目录结构 -
problemMatcher只解析输出文本，不解决路径问题；它只是帮你把tsc错误定位到对应行，不能掩盖执行上下文差异
tasks.json 里的 env 和 GitHub Actions 的 env 不互通
VSCode 任务中的 "env" 是进程级环境变量，只影响该 shell 子进程；GitHub Actions 的 env 是 job 或 step 级，且需明确定义。两者不会自动同步，也不能靠“同名变量”隐式继承。
- 本地开发常用
"env": { "NODE_ENV": "development" }，但 CI 里必须在 workflow YAML 中重复定义：jobs:<br> build:<br> env:<br> NODE_ENV: production
- 敏感值（如 API keys）绝不能硬编码进
tasks.json；CI 里要用${{ secrets.MY_KEY }}，本地则应走.env+dotenv加载 - 跨平台差异：Windows 下
set PORT=3000 && npm start在 Linux CI 里会直接报错；统一用cross-env PORT=3000 npm start，并确保本地和 CI 都装了cross-env
如何让 problemMatcher 和 GitHub Actions 的日志解析行为一致
problemMatcher 是 VSCode 用来把终端输出转成可跳转错误的规则，GitHub Actions 没有等价机制——它只原样输出 stdout/stderr。所谓“一致”，是指用同一套正则去捕获关键错误信息，否则本地能定位，CI 日志里就得手动 grep。
- 推荐复用 VSCode 内置 matcher，比如 TypeScript 项目用
$tsc，它匹配形如src/index.ts(5,10): error TS2304: Cannot find name 'foo'.的格式；CI 中也要确保tsc输出未被重定向或压缩（别加--silent） - 自定义 matcher 时，正则必须用双反斜杠：
"pattern": { "regexp": "^(.*):(\d+,\d+):\s+(error|warning)\s+(TS\d+):\s+(.*)$" }，CI 不解析这个，但你写错了，本地也匹配不上 - CI 日志里看不到红色波浪线，但你可以用
grep -n "error TS"快速定位；真正要的是错误格式统一，而不是 UI 表现一致
触发时机错位：保存即运行 task ≠ push 后触发 Action
VSCode 的 "runOn": "save" 是编辑器行为，GitHub Actions 的 on: push 是 Git 事件驱动，二者无技术耦合。所谓“联动”，是你主动把本地验证通过的代码提交上去，而不是编辑器自动发请求调用 Action。
- 别在
tasks.json里写"command": "git push"自动推送——这绕过代码审查，且无法控制分支策略 - 想提前拦截问题，就把 lint/test 命令设为
"runOn": "save"，但注意性能：大型项目每次保存都跑完整 test suite 会卡住编辑器 - CI 的真正价值不在“替代本地”，而在“验证本地不可控的部分”：比如多 OS 测试、真实依赖版本、并发构建冲突——这些你本地根本模拟不了
本地和云端永远存在执行边界：一个是开发者机器上的进程，一个是 runner 实例上的容器。所谓高度一致，本质是人为收敛差异点——命令相同、路径显式、变量显式、输出格式统一、失败语义一致。最容易被忽略的，是把 tasks.json 当配置文件来维护，却忘了它只是脚本入口，真正的契约在 package.json 脚本和 CI YAML 里。
