VS Code tasks.json 怎样固定任务使用的 shell

如果 VS Code 的任务在不同电脑上表现不一致，先看任务实际使用的 shell。集成终端右上角选择的默认 profile，不一定等于 Tasks 使用的自动化 shell。更稳定的做法是：用 terminal.integrated.automationProfile.* 固定工作区的任务 shell；只有某个任务需要特殊解释器时，再在 .vscode/tasks.json 里用 options.shell 做局部覆盖。

官方地址：https://code.visualstudio.com/docs/debugtest/tasks

统一规则写入工作区设置，特殊规则写入任务本身。这样可以把“所有任务都用什么 shell”和“这个任务例外用什么 shell”分开维护。

一、先分清普通终端和自动化任务

打开命令面板，执行“Preferences: Open Workspace Settings (JSON)”。这里修改的是当前工作区的 .vscode/settings.json，影响范围比用户设置小，适合和项目一起说明任务约定。普通终端 profile 主要决定手动打开的终端，任务则读取自动化 profile。

如果工作区还没有 .vscode 目录，保存设置时 VS Code 会创建它。要让团队共享这项约定，应提交 .vscode/settings.json；不要把个人账号、密钥或本机私有路径写进去。

二、用 automationProfile 固定工作区任务 shell

在设置 JSON 中按操作系统写对应键。下面示例只保留常用路径，JSONC 注释说明了每一组设置的作用；实际项目只保留团队需要的平台。

{
  // 任务、调试前置任务等自动化入口统一使用 zsh。
  "terminal.integrated.automationProfile.osx": {
    "path": "/bin/zsh"
  },
  // Linux 工作区可以显式固定为 bash，避免依赖机器默认值。
  "terminal.integrated.automationProfile.linux": {
    "path": "/bin/bash"
  },
  // Windows 任务按项目约定使用 PowerShell。
  "terminal.integrated.automationProfile.windows": {
    "path": "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe"
  }
}

这一步解决的是“当前平台的自动化任务默认用谁”。它不会把所有开发者的系统 shell 改成同一个值，也不会替代任务脚本中的命令参数。路径必须是目标电脑真实存在的解释器路径；团队跨平台协作时，最好同时提供 osx、linux 和 windows，避免只写一个平台的配置造成另一端回退。

三、特殊任务再用 options.shell 覆盖

若一个任务必须使用不同 shell，执行“Terminal: Configure Tasks”，选择“Create tasks.json from template”，再选择“Others”。在生成的 .vscode/tasks.json 中把覆盖写到任务的 options.shell 下。

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "项目检查（固定 Bash）",
      "type": "shell",
      "command": "printf",
      "args": ["task shell configured\\n"],
      "options": {
        "shell": {
          // 该任务覆盖工作区默认 automationProfile。
          "executable": "/bin/bash",
          "args": ["-c"]
        }
      },
      "problemMatcher": []
    }
  ]
}

options.shell 可以放在单个任务中，也可以按平台放在任务的 osx、linux 或 windows 属性下。不要为了“看起来统一”把所有任务都写一遍覆盖：没有特殊要求的任务保留全局自动化 profile，配置更容易维护。

四、从 Run Task 入口确认配置范围

1. 打开命令面板，执行“Tasks: Run Task”，选择刚才的“项目检查（固定 Bash）”。
2. 观察集成终端是否出现任务标签与预期输出；任务成功完成后，回到 tasks.json 检查 options.shell 是否仍属于这个任务。
3. 再运行一个没有局部覆盖的普通任务，比较它是否遵循 automationProfile。如果两个任务表现一致，说明当前工作区默认规则已经覆盖到任务入口。

这里的确认重点是“配置从哪个入口生效”，不是把集成终端的外观当成任务 shell 的证明。任务支持前提是已经打开工作区文件夹；只打开单个文件时，工作区任务能力本身不可用。

五、任务仍不生效时按这四项排查

最小维护原则是：工作区统一规则放 settings.json，任务例外放 tasks.json，命令本身不要偷偷依赖个人 shell 启动脚本。这样排查时只需沿着“工作区设置 → 任务覆盖 → 平台路径 → PATH”检查。

相关问题

automationProfile 会修改我手动打开的终端吗？

它针对 VS Code 自动化场景，包含 Tasks；手动终端应单独检查 terminal profile 设置。

为什么任务里写了 options.shell 还不生效？

先确认任务确实是 type: "shell"，并检查平台专属属性是否覆盖了通用属性，同时确认解释器路径存在。

应该把 shell 配置写用户设置还是工作区设置？

项目任务需要团队一致时写工作区设置；只服务个人习惯时写用户设置。项目配置不要包含私有路径和凭据。

总结一下：先用 terminal.integrated.automationProfile.* 固定任务默认 shell，再用任务级 options.shell 处理少数例外，最后从“Tasks: Run Task”验证实际入口和作用域。