首页 > Golang > Go教程

Go types.Config.Error 怎样收集多个类型错误而非只保留首条

来源：17golang原创

时间：2026-11-10 15:39:18 149浏览收藏

我在用 go/types 做源码分析时，最先遇到的不是类型推断，而是诊断信息太少：types.Config 的 Error 字段如果保持为 nil，类型检查通常在发现第一个错误后就停止。要收集同一轮检查中发现的多个错误，需要给 Config.Error 安装回调；同时，Config.Check 返回的 error 仍然是首个错误，不能把它误认为完整的错误列表。

实际写法是：回调里把每个错误追加到切片，Check 返回后再根据切片生成诊断报告。官方文档还特别说明，回调收到的错误动态类型是 types.Error；某些次生错误的错误字符串会以制表符开头。因此，收集、分类和最终是否接受这个包，需要分成三个判断。

Config.Error 为 nil 时为什么只剩一条

Config 的零值可以直接使用，但它的 Error 默认是 nil。这种配置下，类型检查器找到错误后会停止；Check 的返回值就是第一个错误。这个行为适合只关心“能否通过检查”的短路径，却不适合编辑器、静态分析器或批量报告工具，因为用户修复一处后还要重新运行才能看到下一处。

这里有两个容易混在一起的对象：

Config.Error：每发现一个类型错误时调用一次的回调入口。
Config.Check 的返回值：检查结束后返回的首个错误；即使回调收集到了多个错误，也不会自动变成切片。

所以，想拿到多条错误，关键不是反复调用 Check，而是在同一次检查前设置回调。

给 Config.Error 安装错误收集回调

下面的示例只展示收集关系，不依赖本地执行结果。闭包捕获一个错误切片，类型检查器每次调用回调时追加一项；Check 返回的首个错误则单独保留，便于兼容只接受一个 error 的调用方。

package main

import (
    "fmt"
    "go/ast"
    "go/parser"
    "go/token"
    "go/types"
)

func collectTypeErrors(src string) ([]error, error) {
    fset := token.NewFileSet()
    file, parseErr := parser.ParseFile(fset, "sample.go", src, parser.AllErrors)
    if parseErr != nil {
        return nil, fmt.Errorf("解析源码失败: %w", parseErr)
    }

    var collected []error
    conf := types.Config{
        // 非 nil 回调会让检查器继续报告后续发现的类型错误。
        Error: func(err error) {
            collected = append(collected, err)
        },
    }

    // Check 的返回值仍表示首个错误，不能替代 collected。
    _, checkErr := conf.Check("example", fset, []*ast.File{file}, nil)
    return collected, checkErr
}

Go types.Config、Check、Error 回调和错误切片之间的静态关系说明图 — 图1：Config.Error 回调把类型检查器发现的每个错误交给收集容器；这是静态结构图，不是运行截图。

这个函数的返回值故意保留两个通道：第一项是回调收集到的所有错误，第二项是 Check 返回的首个错误。常见的调用方式是先遍历第一项生成编辑器诊断，再用第二项判断包是否未完成。

types.Error 里应该展示哪些信息

回调参数的静态类型是 error，但官方文档说明它的动态类型是 types.Error。这个错误对象包含 Fset、Pos、Msg 和 Soft 等信息。把它断言成 types.Error 后，可以用文件集把位置转换成编辑器能够理解的文件名、行号和列号。

func formatTypeError(err error) string {
    typeErr, ok := err.(types.Error)
    if !ok {
        // 兼容非 types.Error 的外围错误，至少保留原始文本。
        return err.Error()
    }

    position := "未知位置"
    if typeErr.Fset != nil {
        // Fset.Position 将 token.Pos 转换为文件、行、列信息。
        position = typeErr.Fset.Position(typeErr.Pos).String()
    }

    severity := "硬错误"
    if typeErr.Soft {
        // Soft 错误仍可能允许包得到一个可继续分析的解释。
        severity = "软错误"
    }
    return fmt.Sprintf("[%s] %s: %s", severity, position, typeErr.Msg)
}

Soft 不是“可以忽略”的意思。它只表示这个错误仍允许类型检查器对包作出某种有效解释，例如未使用变量一类问题。对于源码诊断工具，最好把它作为严重级别或标签展示，而不是直接丢弃。

首个错误、次生错误和不完整 Package 要分开

多错误回调解决的是“如何收集更多诊断”，没有改变类型检查失败的含义。官方文档把部分次生错误定义为错误字符串以 \t 开头的条目；它们有时只是为了补充说明同一个根因。报告界面可以展示它们，但如果要统计独立问题，不能简单按错误条数当成问题数。

另一方面，Check 返回的 Package 在出现错误时可能是不完整的。即便回调里有多条信息，也不要把返回的包当成已经通过类型检查的完整包。比较稳妥的结果模型是：

信息	用途	处理建议
收集切片	展示全部已发现的诊断	按位置排序或保留检查器给出的顺序
Check 返回的 error	兼容单错误接口、快速判断失败	保留为首个错误，不当作完整列表
types.Error.Soft	区分软错误与硬错误	作为严重级别，不等同于忽略
Package 状态	判断类型信息能否继续使用	有错误时按不完整包处理

types.Error、位置消息、Soft 标志、次生错误和不完整 Package 的静态关系说明图 — 图2：首个错误、次生错误和不完整 Package 是不同诊断信息；这是静态结构图，不是运行截图。

把收集逻辑封装成源码分析器的结果

当文章示例升级成真正的源码分析工具时，我更倾向于把“原始错误”和“展示文本”分开保存。原始 error 用于判断和后续分类，位置化文本用于输出 JSON、编辑器协议或命令行报告。这样既不会因为格式化需求丢失 Soft，也不会让 UI 层重新猜测错误位置。

type TypeCheckResult struct {
    Errors   []error
    FirstErr error
}

func checkFiles(path string, fset *token.FileSet, files []*ast.File) TypeCheckResult {
    result := TypeCheckResult{}
    conf := types.Config{
        // 回调只负责收集，不在这里决定错误是否可忽略。
        Error: func(err error) {
            result.Errors = append(result.Errors, err)
        },
    }

    // Check 返回首个错误；Package 若有错误则只能作为不完整结果使用。
    _, result.FirstErr = conf.Check(path, fset, files, nil)
    return result
}

在外层使用时，可以先判断 len(result.Errors) 是否为零；非零时逐条格式化，并把 result.FirstErr 传给需要单一错误的旧接口。不要在回调里直接 panic 或提前返回一个错误来模拟“停止”，因为那会把多错误收集重新变成首条错误模式。

几个容易踩到的边界

解析错误与类型错误不是一回事：parser.ParseFile 的语法问题应先单独处理；Config.Error 负责的是类型检查阶段发现的错误。
不要重复调用 Check 来凑列表：重复检查会增加成本，也可能让调用方误以为每次得到的是不同层次的诊断。
不要无条件把所有错误降级：回调继续接收错误只是为了改善报告体验，硬错误仍然应让结果保持失败状态。
共享切片要有明确边界：回调在这次检查期间写入切片，调用方在 Check 返回后读取；如果外层再并发处理，先复制或转换成自己的结果结构。

小结

Go types.Config.Error 想收集多个类型错误，核心就是设置一个非 nil 回调，并在回调中保存每个错误。Check 的返回值仍是首个错误，types.Error 的位置、消息和 Soft 字段适合用于结构化诊断，而出现错误时返回的 Package 应按不完整结果对待。把这三层信息分开后，源码分析器才能同时做到“多报问题”和“正确判断检查失败”。