Go go/types.Config.Check 怎样通过错误回调定位类型问题

用 go/types.Config.Check 做源码分析时，最容易漏掉的是错误回调的语义：Config.Error 非空时，类型检查器会把发现的每条错误交给回调；Check 仍然只通过返回值给出第一个错误。要把问题稳定定位到源码，关键是让解析、类型检查和 token.FileSet 共用同一套位置坐标。

官方文档：https://pkg.go.dev/go/types#Config

实用写法是：在 Config.Error 中收集诊断，在 Check 返回后单独判断首个错误，再用 types.Error.Pos 配合 FileSet.Position 输出文件、行和列。回调收集到多条错误，并不代表返回的 error 可以忽略。

先分清回调和 Check 返回值

Config.Error 是一个 func(error)。它不负责替代 Check 的返回值，而是把检查过程中发现的错误逐条交给调用方。当回调为 nil 时，检查器遇到第一条错误就会停止；当回调非空时，检查器可以继续报告后续问题。

Check 返回的第二个值仍是“第一个错误”。因此代码应同时保存两个面：一个是用于日志、编辑器诊断或批量展示的 diagnostics，另一个是决定当前包是否可接受的 checkErr。

准备带位置的 AST 输入

下面的示例用字符串模拟一份待分析源码。示例故意让变量赋值产生类型问题，重点不在复现某个具体输出，而在展示位置如何从解析阶段传到类型检查阶段。所有代码注释都放在代码块内部，方便读者直接复制后再替换输入来源。

package main

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

// Diagnostic 是面向日志或编辑器的稳定诊断结构。
type Diagnostic struct {
	Filename string
	Line     int
	Column   int
	Message  string
	Soft     bool
}

// parseSource 用同一个 FileSet 保存 AST 中每个 token 的位置。
func parseSource(src string) (*token.FileSet, *ast.File, error) {
	fset := token.NewFileSet()
	file, err := parser.ParseFile(fset, "sample.go", src, parser.AllErrors)
	if err != nil {
		// 语法错误发生在类型检查前，先把它作为输入错误返回。
		return fset, nil, err
	}
	return fset, file, nil
}

// errorToDiagnostic 把 go/types.Error 的 Pos 映射成可读的位置。
func errorToDiagnostic(err error, fset *token.FileSet) Diagnostic {
	var typeErr types.Error
	if errors.As(err, &typeErr) {
		pos := fset.Position(typeErr.Pos)
		return Diagnostic{
			Filename: pos.Filename,
			Line:     pos.Line,
			Column:   pos.Column,
			Message:  typeErr.Msg,
			Soft:     typeErr.Soft,
		}
	}
	// 非 types.Error 的错误没有可用的源码位置，保留原始文本。
	return Diagnostic{Message: err.Error()}
}

把 Error 回调接到 Config.Check

类型检查前创建一个切片收集回调参数，然后把同一个 FileSet 和 AST 文件传给 Check。这里不需要自己解析错误字符串；官方的 types.Error 已经提供了 Fset、Pos、Msg 和 Soft 字段。

// checkPackage 收集所有诊断，同时保留 Check 返回的首个错误。
func checkPackage(src string) ([]Diagnostic, *types.Package, error) {
	fset, file, err := parseSource(src)
	if err != nil {
		return nil, nil, err
	}

	diagnostics := make([]Diagnostic, 0, 4)
	conf := types.Config{
		// 回调非空后，检查器会继续把发现的错误交给调用方。
		Error: func(err error) {
			diagnostics = append(diagnostics, errorToDiagnostic(err, fset))
		},
	}

	pkg, checkErr := conf.Check("demo", fset, []*ast.File{file}, nil)
	if checkErr != nil {
		// checkErr 是首个错误；diagnostics 可能已经包含多条错误。
		return diagnostics, pkg, checkErr
	}
	return diagnostics, pkg, nil
}

// printDiagnostics 展示定位结果，不把回调结果误当成成功标志。
func printDiagnostics(diagnostics []Diagnostic, checkErr error) {
	if checkErr != nil {
		fmt.Println("首个类型检查错误：", checkErr)
	}
	for _, item := range diagnostics {
		level := "hard"
		if item.Soft {
			level = "soft"
		}
		fmt.Printf("%s:%d:%d [%s] %s\\n", item.Filename, item.Line, item.Column, level, item.Message)
	}
}

为什么要保留 types.Error 的字段

回调参数的动态类型是 types.Error。其中 Pos 是位置，Msg 是不带位置前缀的诊断文本，Soft 表示这个错误是否仍允许包得到一种有效解释。把它们转换成自己的结构后，后续无论是 JSON、日志还是编辑器协议，都不必依赖 filename:line:column: message 这种展示字符串。

FileSet.Position 会把 token.Pos 变成包含文件名、行号和列号的 token.Position。这也是为什么解析与检查阶段必须共享同一个 FileSet；如果重新创建位置集合，得到的偏移就没有同一坐标系可解释。

三个容易误判的边界

回调收集到多条错误，不等于包检查成功

只要 checkErr 非空，就应按失败或不完整包处理。回调的价值是让调用方能一次展示更多问题，而不是改变 Check 的成功语义。

次生错误不适合直接当独立根因

官方文档说明，某些次生错误的文本会以制表符开头，例如递归类型声明相关的连带诊断。展示时可以照原文保留；如果要折叠诊断，应把它标记为关联信息，不要简单按字符串排序后声称每条都是独立根因。

语法错误和类型错误是两层输入

parser.ParseFile 失败时还没有可靠的完整 AST，应该先处理解析错误；只有成功获得 AST 后，才进入 Config.Check。把两类错误统一进自己的 Diagnostic 结构是可以的，但要保留来源阶段字段，避免排查时把语法错误误认为类型检查错误。

用一张表快速选择处理方式

总结

go/types.Config.Check 的正确接法不是在回调和返回值之间二选一：回调用来收集每条诊断，返回值用来判断首个错误和包是否完整。只要解析、类型检查共用同一个 token.FileSet，就能从 types.Error.Pos 稳定得到源码位置；再把 Msg、Soft 一并转成业务诊断结构，后续输出格式就不会被官方错误字符串绑死。

相关问题

• Config.Error 为 nil 时会怎样？类型检查遇到第一条错误就停止，Check 返回该错误。
• 为什么回调里的错误能定位到文件？types.Error.Pos 与解析时使用的 token.FileSet 属于同一位置坐标。
• Soft 为 true 是否可以忽略？不建议直接忽略；它表示错误仍允许一种有效解释，但是否继续使用包要由工具目标决定。
• 可以只用 err.Error() 解析行号吗？可以显示，但不适合作为结构化定位方案，优先使用 Pos 和 FileSet.Position。