Go test -json 怎样定位测试输出来自哪个包

go test -json ./... 的输出不是一整段按包排列的文本，而是多包事件交错出现的 JSON 流。定位测试输出时，先把每行解码成事件，再用测试事件里的 Package 作为归档键，把 Output 追加到对应包；如果遇到构建事件，则改看 ImportPath 或 FailedBuild。这样即使多个包并行测试，也不会因为输出交错而归错包。

官方文档：https://pkg.go.dev/cmd/go

为什么 Package 字段能定位测试包

-json 的目标是把测试输出转换成适合自动处理的 JSON。官方 test2json 说明中，事件至少围绕 Action、Package、Test、Output 等字段组织；当多个包并行时，不同包的事件可能交错，但 Package 仍然告诉你当前事件属于哪个包。

# 让 go test 处理模块内的所有包，并把事件流保存为 JSONL
go test -json ./... > test-events.jsonl

一行事件可以是包整体的开始或结束，也可以是某个测试函数的输出。不要把 Test 当成包名：包级事件通常没有 Test，而同一个包下的多个测试又可能分别出现。对归档器来说，Package 应作为一级键，Test 作为可选的二级信息。

按事件字段归档 Output

真正处理日志时，核心是逐行解码，而不是先按空行或日志前缀切段。下面的示例只保留定位包所需字段：Action 判断事件类型，Package 决定归档位置，Output 保留原始输出。字段缺失是正常情况，程序应允许一行事件没有 Test。

package main

import (
    "bufio"
    "encoding/json"
    "fmt"
    "os"
)

type event struct {
    Action  string `json:"Action"`
    Package string `json:"Package"`
    Test    string `json:"Test"`
    Output  string `json:"Output"`
}

func main() {
    scanner := bufio.NewScanner(os.Stdin)
    // 单行输出可能较长，适当扩大 Scanner 缓冲区，避免截断事件。
    scanner.Buffer(make([]byte, 64*1024), 4*1024*1024)
    for scanner.Scan() {
        var e event
        if err := json.Unmarshal(scanner.Bytes(), &e); err != nil {
            // 保留坏行上下文，便于区分非 JSON 错误输出与正常事件。
            fmt.Fprintf(os.Stderr, "无法解析事件: %v\\n", err)
            continue
        }
        if e.Action != "output" || e.Package == "" {
            // 这里只归档测试输出；构建事件在后文单独处理。
            continue
        }
        fmt.Printf("[%s] %s", e.Package, e.Output)
    }
    if err := scanner.Err(); err != nil {
        // 读取流失败时返回非零状态，让上层任务知道归档不完整。
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

这个程序把测试输出按包名分组，但仍保留了测试事件的原始顺序。若要做更细的报表，可以把 Test 作为二级键；不过不要假设每一条 Output 都有测试名，包级输出和测试框架输出可能没有这个字段。

构建事件为什么要看 ImportPath

只读取 Package 会漏掉编译阶段的问题。go test -json 同时报告构建输出，构建事件的结构是 ImportPath、Action 和 Output；其中 build-output 表示构建工具输出，build-fail 表示构建失败。测试事件中的 FailedBuild 也会给出导致测试失败的包标识。

因此，生产归档器应先看 Action 再选择包字段：测试事件优先使用 Package，构建事件使用 ImportPath，测试失败事件在 FailedBuild 非空时补充构建包。图2把这几个字段的边界放在一起，避免把同名的“包”概念当成同一个 JSON 字段。

多包排障时的四个处理要点

# 禁用成功测试缓存，让同一组排障命令重新产生事件
go test -json -count=1 ./... > test-events.jsonl

# 只查看某个包的事件，仍然按 JSON 字段过滤，不按文本块猜边界
jq 'select(.Package == "example.com/project/service")' test-events.jsonl

• 事件可能交错：按 Package 聚合，不要假设一个包的所有行连续出现。
• 包级事件可能没有 Test：归档主键不要依赖测试名。
• 构建输出不是测试输出：遇到 ImportPath、build-fail 或 FailedBuild 时切换字段。
• 缓存会改变复查感受：需要确认测试真的再次执行时使用 -count=1，但不要把缓存状态误写成包定位结论。

常见问题

为什么不能用输出文本里的测试名判断包？

测试名只说明某个测试函数，包级输出可能没有测试名，而且不同包可能使用相同的测试名。Package 才是事件提供的包归属字段。

go tool test2json 能不能直接替代 go test -json？

它适合把单个测试二进制的输出转换成事件流；需要同时处理多个包时，优先使用 go test -json，因为 go 命令会携带每个包的标识并处理构建事件。

为什么解析后还有非 JSON 文本？

严重的早期错误可能写到标准错误，即使启用了 -json 也不保证所有字节都是事件。解析器应把标准错误单独保留，不能把它强行当成某个包的 Output。