Go TypeAndValue.IsNil 怎样识别源码里的未类型化 nil

在写 Go 静态分析器时，我遇到过一个很容易误判的场景：源码里明明出现了 nil，但把整棵表达式放进 go/types.TypeAndValue 后，IsNil() 却不是每次都返回 true。原因不在于 nil 失效，而在于这个方法判断的是“当前表达式是否指向预声明值 nil”，不是判断某个运行时结果是否为空。

TypeAndValue.IsNil() 只适合识别当前 AST 节点是否就是源码里的预声明 nil。在官方实现里，判定条件是该记录处于 value 模式，并且类型是 types.Typ[types.UntypedNil]；像 (*int)(nil) 这样的完整转换表达式属于类型为 *int 的值，不能用同一个结果代替。

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

语言规范：https://go.dev/ref/spec#Nil_values

IsNil 判断的到底是哪一个表达式

TypeAndValue 是 go/types 为某个表达式记录的类型和值信息。它的接收者并不知道你在业务上把这段代码称为“空指针”“空切片”还是“nil 比较”；它只关心当前记录对应的 AST 表达式。

官方源码把方法实现收敛成两个条件：

func (tv types.TypeAndValue) IsNil() bool {
	// 只有表达式被记录为一个值时，才进入 nil 值判断。
	return tv.mode == value && tv.Type == Typ[UntypedNil]
}

文章中的代码用源码概念表达这个判断，实际调用时只需要写 tv.IsNil()。关键是不要把这段内部条件理解成“只要值为空就为 true”：IsNil 识别的是预声明标识符 nil 在类型检查结果中的身份。

从 types.Info.Types 取出对应的 TypeAndValue

要分析一个文件里的表达式，通常先把解析得到的 AST 交给 types.Config.Check，再在 types.Info.Types 中按 AST 节点查找记录。下面的示例同时保留了三类节点：nil 标识符、(*int)(nil) 的完整调用表达式，以及 p == nil 的完整比较表达式。

package main

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

func main() {
	const source = `package sample

var p *int
var _ = p == nil
var _ = (*int)(nil)
`

	fset := token.NewFileSet()
	file, err := parser.ParseFile(fset, "sample.go", source, 0)
	if err != nil {
		panic(err) // 解析失败时没有可靠的 AST，不能继续查 TypeAndValue
	}

	info := &types.Info{
		Types: make(map[ast.Expr]types.TypeAndValue), // 保存每个表达式的类型和值记录
	}
	conf := &types.Config{}
	if _, err := conf.Check("sample", fset, []*ast.File{file}, info); err != nil {
		panic(err) // 类型检查失败时先处理错误，不把不完整记录当作有效 nil
	}

	ast.Inspect(file, func(node ast.Node) bool {
		expr, ok := node.(ast.Expr)
		if !ok {
			return true
		}
		tv, ok := info.Types[expr]
		if !ok {
			return true // 并非每个 AST 节点都会产生 TypeAndValue
		}

		if ident, ok := expr.(*ast.Ident); ok && ident.Name == "nil" {
			fmt.Printf("nil: type=%v isNil=%t\\n", tv.Type, tv.IsNil())
		}
		return true
	})
}

这里最重要的不是打印格式，而是查询粒度：info.Types 的键是具体的 ast.Expr 节点。遍历时拿到的 *ast.Ident 如果正好是预声明的 nil，它的 TypeAndValue 才适合直接调用 IsNil。

nil、类型化 nil 和 nil 比较不是同一个节点

把同一段源码拆开看，三个看似相近的表达式承担了不同语义。nil 是预声明标识符；(*int)(nil) 是一次转换调用，整个表达式的类型已经是 *int；p == nil 则是比较表达式，整体结果是 bool。只有它们内部的那个 nil 标识符仍然是直接的 nil 节点。

这也是静态分析器最常见的边界：如果业务需求是“找到所有源码中的 nil 写法”，应遍历并识别 *ast.Ident 节点；如果需求是“报告每个表达式的类型”，则应读取完整表达式对应的 TypeAndValue.Type。两者不能只靠一条 IsNil 结果完成。

把 Type、Value 和 IsNil 分工

TypeAndValue.Type 适合回答“这个 AST 节点的静态类型是什么”；Value 主要为常量表达式提供常量值；IsNil 则是一个更窄的语义快捷判断。它们的分工可以写成下面这张速查表：

如果分析器既要识别 nil，又要生成诊断信息，建议保留三项结果，而不是只返回一个布尔值：

type ExprReport struct {
	Type  types.Type
	Value constant.Value
	IsNil bool
}

func report(tv types.TypeAndValue) ExprReport {
	// Type 保留静态类型，Value 保留常量信息，IsNil 专门记录源码 nil 身份。
	return ExprReport{
		Type:  tv.Type,
		Value: tv.Value,
		IsNil: tv.IsNil(),
	}
}

上面的结构体需要额外导入 go/constant。如果项目只关心 nil 标识符，可以只保存 IsNil；但一旦要解释“为什么它不是 nil”或展示类型差异，保留 Type 会让诊断更完整。

类型检查报错时不要误判为 nil

类型检查器可能因为源码本身不合法而返回错误。此时某些节点可能拥有不完整或无效的类型信息，分析器不应把“没有记录”“类型为无效类型”和“IsNil 为 true”混成一类。

func nilExpr(tv types.TypeAndValue, ok bool) (bool, bool) {
	if !ok || tv.Type == nil {
		return false, false // 第一个 false 是结果，第二个 false 表示记录不可用
	}
	if !tv.IsValue() {
		return false, true // 有记录但不是值表达式，例如类型表达式或内建函数
	}
	return tv.IsNil(), true // 只在有效值记录上解释 IsNil
}

这个返回值设计把“没有结论”和“结论为否”分开了：第一个布尔值是 nil 判断，第二个布尔值表示记录是否可解释。对批量扫描、编辑器诊断或重构工具来说，这比遇到缺失键就默认返回 false 更容易追踪问题。

静态分析器的落地原则

1. 要找源码中的预声明 nil，优先锁定 ast.Ident 节点，再查对应的 TypeAndValue。
2. 要报告整体表达式类型，查询父级 ast.CallExpr、ast.BinaryExpr 等节点，不要复用子节点的类型。
3. 要解释类型化 nil，联合展示 IsNil、Type 和表达式文本，避免把“值可为 nil”写成“源码就是 nil”。
4. 要处理错误源码，区分缺少记录、无效类型和明确的 IsNil() == false。

一句话总结：TypeAndValue.IsNil 是源码语义识别器，不是运行时空值检测器。把 AST 节点选准，再用 IsNil 识别预声明 nil，用 Type 描述静态类型，用 Value 补充常量信息，静态分析结果就不会被类型化 nil 带偏。

相关问题

TypeAndValue.IsNil() 能判断一个指针变量运行时是不是 nil 吗？

不能。它只针对类型检查阶段的表达式记录，判断当前表达式是否指向预声明值 nil。运行时指针是否为空属于程序执行状态。

为什么 (*int)(nil) 看起来是 nil，整体却不能直接按 IsNil 处理？

因为整体表达式是一次类型转换，结果类型是 *int。如果要识别源码中写入的 nil，应继续分析转换参数里的 nil 标识符；如果要报告整体类型，则读取转换表达式的 Type。

没有 TypeAndValue 记录时可以默认 IsNil 为 false 吗？

可以把它作为业务层的保守结果，但最好同时保留“记录缺失”的状态。缺失记录和明确判断为非 nil 是两种不同的诊断原因。