VS Code Tasks 怎样把 problem matcher 接到构建输出

如果构建命令只能在终端里打印一串错误，修复位置就要靠人工复制。VS Code Tasks 的 problemMatcher 可以在任务输出中识别文件、行号、列号、级别和消息，把它们放进 Problems 面板，并支持点击跳转。

实际配置时，先判断构建工具的输出格式，再把 matcher 挂在对应的 task 上。输出格式与内置 matcher 不一致时，使用对象形式的正则规则；路径解析错了，通常比正则本身更容易造成“没有问题”的假象。

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

先看清构建输出要被解析成什么

problem matcher 不是构建器，也不会替构建命令生成错误。它只读取任务产生的文本，并尝试抽取这些字段：

• 文件：问题应该落在哪个源文件。
• 位置：行号、列号，或者一个起止范围。
• 级别：通常是 error、warning 或 info。
• 消息：给开发者看的诊断内容。

例如，自定义构建器可以约定一行输出为 src/worker.c(18,7): error - 缺少 return。只要 matcher 的正则能够稳定捕获这五部分，Problems 面板就能建立对应条目。若构建器输出的是别的格式，不能只把 $gcc 或 $go 随便替换上去。

先用内置 matcher 连接普通构建任务

如果工具的输出格式已经被 VS Code 支持，优先使用字符串形式的内置 matcher。下面的示例把一个 Go 构建命令加入默认构建组，并让任务输出交给 $go 解析：

{
  // 这份文件放在工作区的 .vscode/tasks.json 中。
  "version": "2.0.0",
  "tasks": [
    {
      // label 是任务列表里显示的名称。
      "label": "构建 Go 项目",
      "type": "shell",
      "command": "go build ./...",
      // 内置 matcher 负责把 Go 编译输出映射到 Problems。
      "problemMatcher": "$go",
      "group": {
        // 将它设为默认 build task，便于使用构建快捷键。
        "kind": "build",
        "isDefault": true
      },
      "presentation": {
        // 失败时保留输出，方便把原文与 Problems 条目对照。
        "reveal": "always",
        "panel": "shared",
        "clear": true
      }
    }
  ]
}

运行任务后，先看终端输出是否真的包含文件和位置，再打开 Problems 面板。内置 matcher 只对它认识的格式负责；如果输出中的文件名是绝对路径而 matcher 按工作区相对路径解释，结果可能会显示在错误位置，甚至完全没有条目。

输出格式不同就写自定义 matcher

自定义 matcher 使用对象形式，核心是 pattern.regexp 和各捕获组的字段编号。下面匹配本文开头的格式：文件名后面是括号包裹的行列号，随后是级别、短横线和消息。

{
  // 只展示任务中与 matcher 相关的配置片段。
  "problemMatcher": {
    // owner 用于区分这组构建问题，避免和其他工具混在一起。
    "owner": "build",
    "fileLocation": [
      // 构建器输出相对路径时，以工作区根目录作为解析起点。
      "relative",
      "${workspaceFolder}"
    ],
    "pattern": {
      // 示例格式：src/worker.c(18,7): error - 缺少 return
      "regexp": "^(.*)\\((\\d+),(\\d+)\\):\\s*(warning|error)\\s*-\\s*(.*)$",
      "file": 1,
      "line": 2,
      "column": 3,
      "severity": 4,
      "message": 5
    }
  }
}

捕获组编号从 1 开始：第 1 组是文件，第 2、3 组是行列，第 4 组决定问题级别，第 5 组是消息。正则里每一对括号都会影响编号，所以给表达式增加非捕获分组 (?:...) 时，要避免误把字段位置改乱。

fileLocation 是另一个关键点。构建工具打印 src/worker.c 这类相对路径时使用 relative；如果打印的是完整路径，则应按文档配置 absolute，不要为了“能匹配”而在正则里硬编码本机目录。

在 Problems 面板核对四个可见状态

运行任务后按平台打开 Problems 面板，先不要只看问题数量。建议逐项核对：

1. 文件：点击条目能否进入构建器报告的源文件，而不是工作区外的同名文件。
2. 行列：行号和列号是否从 1 开始，并落在实际代码附近。
3. 级别：warning 与 error 的颜色和筛选类型是否对应。
4. 来源：条目的 source 或 owner 是否能说明它来自当前构建任务。

这些字段都正确，说明 matcher 已经接通；如果只有消息而没有跳转位置，优先检查文件字段和 fileLocation，不要先改颜色或面板显示设置。

不生效时按这五项排查

1. 任务是否真的被运行：确认执行的是配置了 matcher 的 task，而不是同一项目里另一个自动发现的任务。
2. 输出是否逐行匹配：复制一条原始构建输出，对照 regexp 检查括号、空格、冒号和短横线；正则只要有一处不一致就不会产生条目。
3. 文件路径是否可解析：相对路径的基准是工作区还是构建器的当前目录，要和 fileLocation 的设置保持一致。
4. 字段编号是否变化：给 regexp 增加捕获括号后，file、line 等编号可能已经指向别的文本。
5. 是否是持续运行任务：watch 模式需要额外描述开始和结束状态，否则 VS Code 可能无法判断这一轮问题何时收集完毕。

一个实用的缩小范围方法是先保留最小的单行输出和最小正则，确认 Problems 能出现一条记录，再逐渐加入多行诊断、路径前缀和后台任务状态。不要在任务没有输出时反复修改 matcher。

配置结果怎么判断是否合适

因此，“接上 problem matcher”并不等于在任务里添加一行字符串。可靠配置至少要同时满足：matcher 挂在正确任务上、正则能命中真实输出、文件路径能映射到当前工作区，以及 Problems 中的定位字段可复查。

相关问题

内置 matcher 和自定义 matcher 怎么选？ 输出格式与 VS Code 已有 matcher 一致时用字符串最省事；工具输出是自定义格式，或者需要自定义 owner、路径和级别时用对象形式。

problemMatcher 会让构建失败吗？ 它主要负责解析问题并呈现诊断，不会替代构建命令的退出码。构建是否失败仍由实际命令和任务执行结果决定。

为什么正则在测试工具里能匹配，Problems 里却没有？ 常见原因是任务输出包含额外前缀、换行方式不同，或配置文件中的反斜杠转义层级不正确。应以任务实际输出为准，再检查 JSONC 字符串中的转义。