Go 类型检查失败后 Info 中的数据还能使用吗

我在给 Go 源码做静态索引时，最容易误判的一件事是：go/types 返回了错误，就把 types.Info 整个丢掉；或者反过来，只要 Info.Types 里还有数据，就把它当成完整类型模型。更稳妥的结论是：类型检查失败后，Info 中已经写入的条目通常仍可用于局部诊断，但它不再代表一个完整、闭合且适合下游决策的包。

官方 API 的边界很清楚：Config.Check 返回检查得到的 *types.Package 和第一个错误；如果传入非空的 Info，各个非空 map 会被填充。发生错误时，包会被标记为 incomplete。因此，判断重点不是“错误后还能不能读”，而是“这次读取的条目是否存在、对应的依赖是否完整”。

失败结果里同时存在两种信号

把结果拆成两层会比较安全。第一层是包级结论：err 是否为空，以及 pkg.Complete() 是否为真。第二层是局部证据：Info.Defs、Info.Uses、Info.Types 等 map 中，某个具体语法节点是否已经有记录。

这几种信号不要互相替代。err != nil 说明检查没有得到无错误结论；pkg != nil 只能说明检查器返回了一个包对象；pkg.Complete() 为假则明确表示包不完整。它们都不能推出“Info 每个字段都为空”。反过来，某个表达式能从 Info.Types 查到类型，也不能推出它的所有引用、常量值和依赖包都已正确解析。

我会把这种结果标记成“可诊断、不可承诺完整”。例如，编辑器仍可以用已经存在的定义和表达式类型提供局部提示；代码生成器、跨包重写器或需要完整方法集的分析，则应把 err 和 Complete() 当成硬门槛。

按字段理解 Info 的可信范围

Info 不是一张“检查成功/失败”的总开关，而是一组按语法节点建立的关系表。常用字段可以这样看：

这里的“可用”有一个前提：你知道自己在消费哪一个节点，并且能接受查不到。不要用 map 的零值代替存在性判断，也不要用一个节点的成功记录覆盖整棵 AST 的状态。

用显式查找读取局部结果

下面的辅助函数只回答一个窄问题：某个表达式有没有被记录类型信息。它不会把缺失条目解释成 interface{}，也不会因为拿到一个 TypeAndValue 就宣称整个包检查成功。

package main

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

// lookupType 只读取当前表达式已经存在的局部类型记录。
func lookupType(info *types.Info, expr ast.Expr) (types.Type, bool) {
    if info == nil || info.Types == nil {
        return nil, false // 没有初始化 Types，不能把缺失当成 any。
    }
    tv, ok := info.Types[expr]
    if !ok || tv.Type == nil {
        return nil, false // 当前节点没有记录，交给调用方处理降级。
    }
    return tv.Type, true
}

func report(pkg *types.Package, err error, info *types.Info, expr ast.Expr) {
    if err != nil {
        fmt.Println("类型检查有错误：", err)
    }
    if pkg != nil && !pkg.Complete() {
        fmt.Println("包级结果不完整，只做局部诊断")
    }
    if typ, ok := lookupType(info, expr); ok {
        fmt.Println("当前表达式类型：", typ.String())
    }
}

真正的项目代码还要保留节点的文件位置、产生该条目的阶段以及关联错误。这样做的价值在于：下游看到一个局部类型时，知道它是“已知结果”，而不是“全局无错误证明”。

把部分 Info 用在诊断，不用在最终承诺

我通常把消费场景分成三类。第一类是符号索引、悬停提示和错误附近的补充信息，它们可以接受局部成功；第二类是单文件级重命名或引用定位，需要同时检查目标对象是否存在，并避开受错误影响的引用链；第三类是跨包代码生成、接口实现判定和完整依赖图，这些操作应在 err == nil 且 pkg.Complete() 为真时才进入正式阶段。

如果使用 Checker.Files 增量加入文件，也要把每次调用返回的错误和当前检查器状态一起记录。增量 API 方便构建编辑器式分析，但它并没有把不完整的文件集合自动变成完整包。遇到导入失败、声明错误或后续错误时，之前积累的 Info 仍可以帮助定位现场，不能直接升级为可发布的语义事实。

可以给结果加一个简单的状态标签：complete 表示包级检查完成，partial 表示存在错误但某些条目可读，missing 表示当前节点没有可消费的记录。这个小区分比返回一个模糊的 nil 或空字符串更容易让调用方做出正确决策。

几个容易踩到的误区

• 误区一：看到 err != nil 就认为 Info 一定为空。实际应按具体 map 和具体节点查询。
• 误区二：看到一个类型就认为包完整。Package.Complete() 和局部条目回答的是不同问题。
• 误区三：用 map 的零值继续生成代码。缺失、未解析和真实的无类型值必须分开处理。
• 误区四：把第一次错误当成唯一边界。Config.Error 的配置会影响错误收集方式，后续错误也可能让依赖链更不可靠。

相关问题

类型检查失败后可以继续做语法高亮吗？

可以，语法高亮主要依赖 AST 和词法信息；如果要叠加类型提示，应把缺失的 Info 条目当成正常降级状态。

Info 中查不到表达式类型是不是类型为 nil？

不一定。它可能是该 map 没有初始化、节点没有被成功分析，或当前表达式不在该字段的记录范围内，应结合 map 是否存在和检查错误判断。

什么时候必须重新做一次无错误检查？

当结果要驱动跨包重写、接口实现结论、代码生成或发布门禁时，重新检查并确认 err == nil、pkg.Complete() 为真更稳妥。

一句话收束：类型检查失败后的 Info 可以作为“已经拿到的局部证据”，但不能当作“整个包已经被证明正确”。让调用方显式区分 error、Complete() 和单条 map 命中，基本就能避开这类边界误用。