Go go/types.Config 怎样给类型检查接入导入器

我第一次用 go/types 做源码分析时，AST 明明已经解析成功，交给 types.Config.Check 却在遇到 import "fmt" 后报“无法导入”。原因通常不是语法树坏了，而是类型检查器需要通过 Config.Importer 找到被导入包。最小修复是给配置接入 importer.Default()，再把 token.FileSet、AST 文件和包路径一起传给 Check。

解析 AST 只负责把源码变成语法树；解析 import 并建立外部包的类型信息属于 go/types 的类型检查阶段。没有 Importer，检查器不知道 fmt、strings 等依赖包的类型从哪里来。

• 输入：已经由 go/parser 得到的 *ast.File 和对应的 token.FileSet。
• 配置：types.Config{Importer: importer.Default()}。
• 结果：*types.Package，以及可选的 types.Info 类型信息。
• 边界：这里只处理一组源码文件和导入解析，不把它扩展成完整工程加载器。

为什么 AST 能解析，Check 却找不到 import

parser.ParseFile 能识别导入声明的语法，但它不会读取 fmt 包的导出对象、函数签名或常量类型。types.Config.Check 在检查选择器表达式时，需要知道 fmt.Println 中的 Println 属于什么对象，于是会调用配置中的 Importer。

如果 Importer 是 nil，零值配置仍然可以检查没有外部依赖的简单文件；一旦需要导入包，类型检查器就可能返回导入错误。这个差异很适合排查：先确认 AST 是否产生，再看错误是否发生在导入解析阶段。

// 这段只验证语法树是否能生成，不负责解析导入包的类型信息。
fset := token.NewFileSet()
file, err := parser.ParseFile(fset, "sample.go", src, parser.AllErrors)
if err != nil {
    return fmt.Errorf("解析源码失败: %w", err)
}

// 到这里有 AST，不代表 types.Config.Check 已经知道 fmt 的定义。
_ = file

用 importer.Default 接入标准导入器

标准库 go/importer 提供了与当前 Go 工具链配套的导入器。把它放进 types.Config.Importer 后，检查器可以为标准库等已安装包加载类型信息。下面的示例把一个文件放进切片，方便以后扩展到同一包的多个文件。

package main

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

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

    // Importer 负责为 import 声明解析外部包的类型信息。
    conf := types.Config{Importer: importer.Default()}
    pkg, err := conf.Check("sample", fset, []*ast.File{file}, nil)
    if err != nil {
        return nil, fmt.Errorf("类型检查失败: %w", err)
    }
    return pkg, nil
}

这里有一个容易忽略的小边界：Check 接收的是 []*ast.File，不是源码字符串。解析和类型检查是两个相邻但独立的阶段。

让 Config 同时收集类型信息

只拿到 types.Package 适合确认检查是否完成；做静态分析时通常还要填充 types.Info。它可以按需保存表达式类型、标识符定义与引用、选择器信息等结果。不要为了“收集全部信息”盲目初始化所有 map，先按分析目标选择需要的字段。

// 只收集本次分析会读取的类型和对象映射，避免无关数据占用空间。
info := &types.Info{
    Types: make(map[ast.Expr]types.TypeAndValue),
    Defs:  make(map[*ast.Ident]types.Object),
    Uses:  make(map[*ast.Ident]types.Object),
}

// Error 回调让检查器继续报告更多问题；最终 err 仍要保留并处理。
conf := types.Config{
    Importer: importer.Default(),
    Error: func(err error) {
        fmt.Printf("类型问题: %v\n", err)
    },
}
pkg, err := conf.Check("sample", fset, files, info)
if err != nil {
    return fmt.Errorf("检查未完成: %w", err)
}

// pkg 和 info 分别承载包级结果与节点级类型信息。
_ = pkg.Scope()
_ = info.Types

Config.Error 不等于“错误已经解决”。它是逐个接收检查错误的回调；调用方仍应检查 Check 的返回错误。若输入存在问题，返回的包可能是不完整的，能否继续分析要由业务决定。

从 Package 和 Scope 读取检查结果

types.Package 描述检查后的包，pkg.Scope() 可以读取包级声明。比如代码索引器想列出顶层函数和类型，就可以从 Scope 开始；想定位某个表达式的具体类型，则读取 types.Info.Types。这两条路径不要混用：Scope 是包级名字空间，Info 是语法节点与类型对象的关联。

// Scope 是包级名字空间；这里只展示读取思路，不把结果当成运行日志。
scope := pkg.Scope()
for _, name := range scope.Names() {
    obj := scope.Lookup(name)
    fmt.Printf("声明 %s: %s\n", name, obj.Type())
}

// Info.Types 面向具体表达式，例如调用参数或二元表达式。
for expr, tv := range info.Types {
    if tv.Type != nil {
        fmt.Printf("表达式类型: %s\n", tv.Type)
    }
    _ = expr
}

Importer 的几个实际边界

第一，Importer.Default 不是完整工程加载器。它适合给一组已经解析的文件补齐导入包类型；如果任务还包含模块、构建标签、多个包、测试变体和依赖图，应该评估 golang.org/x/tools/go/packages 这类更高层工具。

第二，包路径要稳定。Config.Check 的第一个参数是被检查包的路径标识。它不能是空字符串或点号；分析同一包的多个文件时，应使用相同路径并保持文件集合的一致性。

第三，导入器和工具链要匹配。标准导入器读取的是当前环境可用的编译包信息。若分析目标与运行分析器的 Go 版本、架构或构建条件不同，不能只靠修改 Config 掩盖环境差异。

一张表记住配置项怎么选

常见问题

没有 import 时还需要 Importer 吗？

不一定。没有外部依赖的简单文件可以使用零值配置完成部分检查，但一旦源码引用外部包，就应明确配置导入器。

为什么 importer.Default 仍然找不到自定义模块？

标准导入器解决的是它能访问到的编译包信息，不负责替你构造完整模块加载上下文。需要模块、构建标签和依赖图时，应换用更高层的工程加载方案。

Check 返回错误时还能读取 Package 吗？

可以得到一个可能不完整的包对象，但后续分析必须知道它带有错误状态，不能把部分类型结果当成完整结论。

最小接入顺序是什么？

先用 parser 得到 AST，再建立同一套 FileSet，配置 Importer: importer.Default()，最后调用 Config.Check 并处理返回错误。

把 Importer 看成类型检查器的依赖入口，问题就容易定位：AST 负责语法，Importer 负责外部包，Info 负责节点级结果，Package.Scope 负责包级声明。按这四个边界拆开后，go/types.Config 就能从“报无法导入”变成可控的源码分析基础。