Go go/types.Info.Defs 为什么会出现 nil 对象

在 Go 源码分析里，go/types.Info.Defs 的值偶尔会是 nil，这并不自动意味着类型检查器失效。它的语义是：语法位置确实属于“声明标识符”，但这个标识符在当前语境下没有可对应的 types.Object，或者代码已经有类型错误，检查结果不完整。

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

排查时先看标识符所在的语法位置，再看 Config.Check 是否返回类型错误。package 子句中的名称、类型 switch 的临时变量，以及某些错误代码，都可能让 Defs[id] == nil 成为正常或可预期结果；不要把它和 Uses 中的引用对象混为一谈。

先把 Defs 的 nil 放进正确语境

Info 是类型检查结果的容器，只有你实际提供的 map 才会被填充。Defs 记录“这个标识符定义了什么对象”，Uses 记录“这个标识符引用了什么对象”。两者都以 *ast.Ident 为键，但语义不是一回事。

// 这个最小配置只收集定义和引用，便于后续按位置排查。
info := &types.Info{
	Defs: make(map[*ast.Ident]types.Object),
	Uses: make(map[*ast.Ident]types.Object),
}

// Check 会把可得到的定义、引用写入 info；返回错误时结果可能不完整。
pkg, err := (&types.Config{}).Check("example", fset, files, info)
if err != nil {
	// 不要丢掉 info：它仍可帮助定位发生错误的声明位置。
	log.Printf("type check incomplete: %v", err)
}
_ = pkg

这个关系决定了第一条排查原则：Defs[id] == nil 只能说明“当前 map 没有可用对象”，不能单独推出“这个标识符不是声明”。要同时记录 id.Name、语法节点类型、源文件位置和 Check 返回的错误。

识别官方文档列出的 nil 场景

官方 go/types.Info 文档已经明确列出几类“键存在但对象为 nil”或可能没有定义项的情况。工程代码最好把它们当成输入分类，而不是用一个简单的 nil 计数器判断成功率。

特别容易误判的是 package 名称：它看起来像普通的 ast.Ident，但语义上不是包级变量、类型或函数。另一个容易混淆的点是嵌入字段：Defs 关注它定义的字段对象，而 Uses 关注它所表示的类型名，不能只凭名字判断。

用 Info.Defs 与 Info.Uses 组成诊断表

当分析器需要输出“定义列表”时，建议把定义与引用合并到一个以对象为中心的表里。对 Defs 先做 nil 分支，对 Uses 则记录引用对象的位置；这样既不会把正常的语义 nil 报成错误，也能看见同一对象的引用分布。

// 按源代码位置输出定义；nil 只记录为语义边界，不直接判失败。
for id, obj := range info.Defs {
	pos := fset.Position(id.Pos())
	if obj == nil {
		fmt.Printf("%s %q: no defining object\n", pos, id.Name)
		continue
	}
	// Obj 的位置应与声明标识符一致，可用于建立稳定索引。
	fmt.Printf("%s %q: %s\n", pos, id.Name, obj.String())
}

// Uses 的对象是被引用的对象，位置通常不同于当前标识符位置。
for id, obj := range info.Uses {
	if obj == nil {
		continue
	}
	fmt.Printf("use %q -> %s\n", id.Name, obj.Name())
}

上面的输出应该被看成诊断数据，而不是“代码运行结果”。真正写入生产分析器时，还要为每次检查保存一个 complete 标志：没有错误时为完整结果；有错误时，即使部分对象可用，也不能把 map 当成全量事实。

把判断落到源码分析器

如果后续逻辑只接受真实对象，可以把 nil 分支集中在一个小函数里，避免每个调用点重复猜测。函数的职责是分类，不是掩盖错误：

// classifyDef 只把可绑定对象交给后续分析，其余情况保留原因。
func classifyDef(id *ast.Ident, obj types.Object, checkErr error) string {
	if obj != nil {
		return "object:" + obj.Name()
	}
	if checkErr != nil {
		return "nil:incomplete-type-check"
	}
	// 无错误时仍可能是 package 名、_ 或类型 switch 临时变量。
	return "nil:syntax-context"
}

这里没有把所有 nil 都转换成错误，也没有尝试为它们“补造”一个对象。对象是否存在是 go/types 的语义；分析器要做的是带着源位置和上下文继续工作。

一份可以直接照着做的排查清单

1. 确认 Info.Defs 已初始化；没有提供 map 时，类型检查器不会替你补建。
2. 打印 fset.Position(id.Pos())，先确定 nil 所在的语法上下文，而不是先改代码。
3. 检查它是否是 package 名、_ 或类型 switch 的符号变量。
4. 保存 Config.Check 的返回错误；重复声明、缺失导入等错误会让结果不完整。
5. 需要“这个标识符最终指向谁”时，确保 Defs 和 Uses 都已填充，再使用 Info.ObjectOf。
6. 对外输出结果时区分 complete 与 partial，不要把部分 map 包装成完整索引。

相关问题

Info.Defs 和 Info.Uses 能互相替代吗？

不能。Defs 面向定义位置，Uses 面向引用位置；同一个对象可能在 Defs 出现一次，在 Uses 出现多次。

Defs 中没有某个变量，是不是变量没有声明？

不一定。先确认是否初始化了 Defs map，再看是否有类型检查错误，以及该标识符是不是 selector、package 名称或其他不属于 Defs 的语法位置。

有类型检查错误时还能使用 Info 吗？

可以用于定位和提供部分诊断，但必须标记为不完整结果；不能依赖它生成无条件正确的全量符号索引。

总结一下：go/types.Info.Defs 的 nil 要按“对象语义”和“检查完整性”两条轴判断。先看语法位置，再看 Check 错误，最后让分析器在 nil 分支中保留上下文，问题通常就能从“类型检查器为什么丢对象”还原成一个明确的边界。