VS Code 任务已运行却不显示 Problems：problemMatcher、相对路径与后台任务排查

VS Code 里点完运行任务之后，终端已经正常输出了 src/app.ts:7:5: error，但 Problems 面板里什么内容都没显示，这种故障很多人第一反应会以为是插件出问题了。实际排查下来你会发现，任务输出、problemMatcher 和文件路径是三个互相独立的校验环节，只要其中任意一层匹配不上，VS Code 就识别不到能点击跳转的错误条目。

遇到这类故障不需要重装软件或者乱改配置，按从外到内的顺序逐层排查：先确认终端输出正常，再校验匹配器规则，最后对齐路径基准，后台任务额外补充就绪声明就能解决绝大多数情况。

先确认错误到底在哪一层

先不要急着修改正则配置。打开 VS Code 的终端面板，运行任务之后把完整的原始输出留存下来。假设你的项目根目录是 /work/demo，脚本打印的内容类似下面这行：

src/app.ts:7:5: error TS2322: Type 'string' is not assignable to type 'number'.

这行内容已经包含了文件名、行号、列号和错误消息四个必要信息。如果终端连这行输出都没有，问题肯定出在编译命令或者执行脚本本身；如果终端输出正常但 Problems 面板没内容，才需要进入 problemMatcher 环节排查。VS Code 官方规则里说明，problemMatcher 只会解析当前任务的输出内容，不会主动去扫描外部的其他日志文件。

界面上你可以点顶部菜单“终端 > 运行任务”重新触发任务，再点“查看 > Problems”或者按快捷键 ⇧⌘M（Windows/Linux 系统对应 Ctrl+Shift+M）查看结果。这里重点不是记快捷键，而是确认任务确实输出了匹配器预期的单行格式内容。

problemMatcher 没匹配时，先用最小配置测试

如果你用的是 TypeScript 编译器，优先尝试官方内置的 $tsc，它默认输出的文件名是相对于当前打开的工作区目录的。把下面这段配置保存到项目里的 .vscode/tasks.json 文件中：

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "检查 TypeScript",
      "type": "process",
      "command": "npx",
      "args": ["tsc", "--noEmit"],
      "problemMatcher": "$tsc"
    }
  ]
}

按 Ctrl+Shift+B（macOS 系统对应 ⇧⌘B）运行默认构建任务。如果 Problems 面板里正常弹出 app.ts 第 7 行的错误提示，说明编译命令和内置匹配器都工作正常，接下来去检查你原先自定义任务的输出格式或者工作目录配置就好。

如果自定义工具的输出格式不一样，才需要自己编写专属的 pattern。比如你的工具输出格式是 src/app.ts:7:5: error: bad value，可以从最精简的必填字段开始配置：

"problemMatcher": {
  "owner": "typescript",
  "fileLocation": ["relative", "${workspaceFolder}"],
  "pattern": {
    "regexp": "^([^:]+):(\\d+):(\\d+):\\s+(error|warning):\\s+(.*)$",
    "file": 1,
    "line": 2,
    "column": 3,
    "severity": 4,
    "message": 5
  }
}

正则里的捕获组序号必须和字段的映射关系完全对应。要是把 severity 写成固定文本、漏写了列号捕获组，或者正则只匹配到文件名，都会导致面板没法生成完整的错误条目。先只保留 file、line、message 三个核心字段，确认错误能正常出现在面板里之后，再补充其他细节配置。

相对路径和工作区根目录要完全对齐

最常见的“终端明明有错误但面板识别不到”的问题，大概率不是正则写错了，而是路径基准没对上。输出里的 src/app.ts 有可能是相对于项目根目录的，也有可能是相对于脚本执行时切换后的 packages/web。你可以在配置里明确指定基准目录：

"fileLocation": ["relative", "${workspaceFolder}"]

如果你的工具打印的是绝对路径，就把匹配规则设为使用 "absolute"；如果输出只给出了文件名但相同文件名分散在多个文件夹里，先去修正工具的输出格式，别让匹配器自己猜路径。用多根工作区的用户还要注意，${workspaceFolder} 指向的是当前任务所属的工作区文件夹，不一定是整个代码仓库的父目录。

给你个简单的验证顺序：先在终端里打印当前执行目录确认位置，复制一条真实的错误条目，在资源管理器里找到同名的对应文件，最后点 Problems 里的链接看能不能跳转到完全一致的行。如果点条目跳转到了错误的文件，说明匹配器本身已经生效了，接下来只需要修正路径配置，不用再反复调整正则规则。

后台任务必须主动报告就绪状态

开发服务器、文件监听器和 watch 模式的编译任务通常运行之后不会自动退出。任务本身明明已经启动成功了，依赖它的调试任务或者联动任务却一直显示等待中。这种情况你需要同时声明 isBackground 属性，并且给匹配器配置好任务开始和结束的识别规则：

{
  "label": "启动开发服务",
  "type": "shell",
  "command": "npm run dev",
  "isBackground": true,
  "problemMatcher": {
    "owner": "custom",
    "pattern": { "regexp": "^$" },
    "background": {
      "activeOnStart": true,
      "beginsPattern": "^starting server",
      "endsPattern": "^ready on http://localhost:3000"
    }
  }
}

这里配置里的 beginsPattern 和 endsPattern 必须完全匹配终端实际输出的内容。如果开发脚本打印的就绪提示是 Local: http://localhost:3000，你配置的正则却在找 ready on，任务就会一直卡在运行状态没法通知后续任务。把终端里实际输出的文本复制出来测试正则，比凭感觉反复调整效率高很多。

一次只改一层配置，按三个维度验收

排查这类故障的时候，可以把验收步骤固定成三个状态依次确认：

1. 终端状态：任务输出包含预期的错误行，后台任务也打印出了明确的就绪提示行。
2. Problems 状态：错误条目数量符合预期，点击条目可以直接打开对应的文件并定位到正确的行号列号。
3. 依赖状态：启动调试或者其他联动任务的时候，不会再无限等待前置任务完成。

如果改完 tasks.json 之后界面上还是显示旧的结果，可以先停止所有运行中的任务，再执行“开发人员: 重新加载窗口”操作。不要把重新加载当成修复问题的手段，它只是清掉了旧任务的残留状态，真正的配置错误还是要靠新一轮的输出校验来定位。

常见问题

为什么终端有错误但 Problems 面板还是空的？

一般是输出格式完全没有匹配到 problemMatcher，或者任务根本就没有声明对应的匹配器。复制一条原始错误输出，逐行检查文件、行号和错误消息的捕获组配置是否正确。

什么时候适合用内置的 $tsc 匹配器？

TypeScript 编译器输出保持官方默认格式的时候优先使用它。只有你自己改造了工具，修改了字段顺序、路径形式或者严重级别的写法之后，才需要自定义匹配规则。

为什么错误条目能点击却跳转到了错误目录的文件？

说明匹配器已经命中生效了，问题出在 fileLocation 的路径基准配置上。对比任务的执行工作目录、${workspaceFolder} 变量指向的路径和工具实际打印的输出路径，再决定用 relative 还是 absolute 模式。

后台任务为什么一直被其他任务等待？

后台任务配置了 isBackground 属性之后，还需要设置能匹配真实日志的 beginsPattern、endsPattern。没有配置就绪状态识别规则的话，VS Code 没办法判断前置任务什么时候真正可用。

把配置留在后续可以复查的位置

tasks.json 不是写得越复杂就越好用。你可以在配置里留一个能单独运行的最小测试任务，给自定义的 problemMatcher 备注一行真实的示例输出，以后修改脚本日志格式的时候同步更新 beginsPattern 或者字段映射规则，下次再遇到 Problems 面板空白的情况，就能快速判断出问题出在命令、匹配器还是路径环节。