本文介绍在 Go 类型检查阶段（基于 go/types）精准识别 AST 表达式是否具有内置 error 类型的方法，避免依赖字符串比较，推荐使用底层接口结构分析与方法签名验证。
本文介绍在 go 类型检查阶段（基于 `go/types`）精准识别 ast 表达式是否具有内置 `error` 类型的方法，避免依赖字符串比较，推荐使用底层接口结构分析与方法签名验证。
在 Go 的静态分析（如 linter、代码生成器或类型检查工具）中，常需判断某个 AST 表达式 ast.Expr 是否代表 error 类型。初学者容易采用字符串比对（如 t.Type.String() == "error"），但该方式脆弱且不可靠：它依赖格式化输出，无法区分自定义同名接口、受别名（type myerr error）或泛型约束影响，且 Underlying().String() 也不具备稳定性保障。
更健壮的做法是深入类型结构，利用 go/types 提供的类型语义信息进行精确判定。内置 error 类型在 go/types 中被建模为一个具名接口（*types.Named），其底层（Underlying()）恒为一个无名接口（*types.Interface），且严格满足以下两个条件：
- 底层类型是
*types.Interface； - 该接口恰好定义一个方法，且该方法的完整签名等价于
Error() string，即其FullName()返回"(error).Error"。
以下是推荐实现：
import (
"go/ast"
"go/types"
)
func IsError(v ast.Expr, info *types.Info) bool {
typ := info.TypeOf(v)
if typ == nil {
return false
}
intf, ok := typ.Underlying().(*types.Interface)
if !ok {
return false
}
// 内置 error 接口仅含一个方法：Error() string
if intf.NumMethods() != 1 {
return false
}
method := intf.Method(0)
// FullName() 格式为 "(T).Name"；对 error 接口，T 是隐式 error 名称
return method.FullName() == "(error).Error"
}⚠️ 注意事项：
-
勿用
types.TypeString()或String()做类型判断：它们属于调试/显示用途，格式不保证稳定，且会混淆error与interface{Error() string}等效但非同一类型的场景； -
info.TypeOf(v)替代info.Types[v]：info.Types是旧版映射（Go 1.11+ 已标记为 deprecated），应统一使用info.TypeOf(v)获取表达式类型； -
空值防护：务必检查
info.TypeOf(v)是否为nil，防止 panic； -
不依赖方法签名细节（如参数名、返回名）：
FullName()仅校验(receiver).Name，而Error() string的签名一致性由go/types在类型检查时已保证，无需额外解析Signature； - 此方法天然兼容类型别名（如
type MyErr error），因其底层仍是error接口。
总结：判断 error 类型的本质，是确认其底层是否为“仅含 Error() string 方法的接口”。通过 Underlying() 向下挖掘并结合 NumMethods() 与 Method(i).FullName() 进行结构化断言，既符合 Go 类型系统的语义模型，又具备强鲁棒性与可维护性，是 AST 分析中识别 error 的标准实践。
