Go go/types.Info.Scopes 怎样获取语法节点的作用域

如果你在写 Go 静态分析工具，常见问题不是“有没有作用域”，而是“这个 AST 节点对应哪一个作用域”。答案是：先在 types.Info 中提供非 nil 的 Scopes 映射，再把语法树交给 types.Config.Check；类型检查器会把它能记录的节点与 *types.Scope 关联起来。

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

本文围绕一个小场景展开：解析一段 Go 源码，完成类型检查，然后查询文件、函数和控制语句节点的作用域。重点也放在一个容易踩坑的细节上——函数的作用域挂在 *ast.FuncType 上，函数体的 *ast.BlockStmt 不会再得到一份重复的函数作用域。

为什么必须先初始化 Info.Scopes

types.Info 是“按需收集结果”的容器。每个 map 是否为 nil，决定类型检查器是否收集这一类信息。因此只写 var info types.Info，再调用 Check，并不会自动得到作用域映射。

最小骨架可以这样写。示例只展示数据准备和读取关系，Scopes 是关键初始化项：

package main

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

func main() {
    const source = `package demo
func run(limit int) { if limit > 0 { limit-- } }`

    fset := token.NewFileSet()
    // ParseFile 把源码文本变成后续类型检查需要的 AST 文件。
    file, err := parser.ParseFile(fset, "demo.go", source, 0)
    if err != nil {
        panic(err)
    }

    info := &types.Info{
        // 只有提供这个非 nil map，Check 才会填充作用域结果。
        Scopes: make(map[ast.Node]*types.Scope),
    }
    // Check 返回包对象；类型错误时，部分 Info 结果可能不完整。
    pkg, err := new(types.Config).Check("demo", fset, []*ast.File{file}, info)
    if err != nil {
        panic(err)
    }

    fmt.Println("package scope:", pkg.Scope().String())
    // Scopes 的 key 是 AST 节点，value 是该节点定义的 Scope。
    ast.Inspect(file, func(node ast.Node) bool {
        if scope := info.Scopes[node]; scope != nil {
            fmt.Printf("%T => %s\n", node, scope.String())
        }
        return true
    })
}

这里有两个独立入口：info.Scopes 负责从 AST 节点找作用域，pkg.Scope() 负责取得包作用域。包作用域不是某一个文件节点专属的对象，所以不要期待在 info.Scopes[*ast.File] 中得到它。

按节点类型读取对应的 Scope

Scopes 的类型是 map[ast.Node]*types.Scope。这意味着查询时不应只看节点的文本内容，而要保留 parser 生成的节点指针。相同名字的两个局部变量，可能位于完全不同的节点和作用域中。

官方文档列出的常见节点包括 *ast.File、*ast.FuncType、*ast.TypeSpec、*ast.BlockStmt、*ast.IfStmt、*ast.SwitchStmt、*ast.ForStmt 和 *ast.RangeStmt。查询结果可能为 nil，这通常表示当前节点不是作用域定义节点，或者本次类型检查没有收集到完整信息。

func scopeNames(info *types.Info, nodes []ast.Node) map[string][]string {
    result := make(map[string][]string)
    for _, node := range nodes {
        scope := info.Scopes[node]
        if scope == nil {
            // 未记录不等于程序错误，先把节点类型记下来供调用方处理。
            result[fmt.Sprintf("%T", node)] = nil
            continue
        }
        // Names 返回排序后的名称，适合生成稳定的分析结果。
        result[fmt.Sprintf("%T", node)] = scope.Names()
    }
    return result
}

如果分析器还需要判断名称从哪个外层作用域继承，可以从当前 Scope 调用 Parent 或 LookupParent。这一步与 Info.Scopes 的职责不同：前者负责找到节点对应的起点，后者负责沿作用域树做名称查找。

函数体为什么不单独出现在映射里

最容易误读的是函数节点。文档明确说明，函数作用域覆盖函数语法的完整范围，关联到 *ast.FuncType；函数体的 *ast.BlockStmt 不会在 Scopes 中再出现一份同义映射。这样可以避免把参数、命名返回值和函数体局部声明错误地拆成两个函数作用域。

可以用下面的判断记忆它们的分工：

• *ast.File 对应文件级声明范围；
• *ast.FuncType 对应函数参数、命名结果和函数体内声明共同使用的函数作用域；
• *ast.BlockStmt、*ast.IfStmt、*ast.RangeStmt 等节点对应更局部的语句作用域；
• 包作用域从类型检查返回的 *types.Package 获取，Universe scope 则是最外层预声明对象范围。

四个边界要提前处理

第一，Scopes map 必须在 Check 之前创建；如果事后才初始化，已经丢失的结果不会自动补回。第二，Config.Check 返回错误时，Info 可能只完成了部分填充，分析器应把结果标记为不完整，而不是把 nil 当成“没有作用域”。

第三，节点必须来自同一棵已经传给 Check 的 AST；重新 parse 一次再拿新指针查询，当然查不到旧 map 的条目。第四，包作用域不按文件拆分，跨文件分析时要从 pkg.Scope() 统一读取。

如果目标是“某个位置上的名字最终解析到什么对象”，可以先用 Info.Scopes 找到语法节点作用域，再用 Scope.LookupParent 结合 token.Pos 查找。若目标只是遍历 AST，不需要类型信息时，直接使用 ast.Inspect 即可，不必为了遍历额外启动类型检查。

相关问题

Info.Scopes 为空是不是 Check 失败？不一定。最常见原因是没有初始化非 nil 的 Scopes map，也可能是查询了不在支持列表里的节点；只有结合 Check 的错误和节点类型一起判断。

为什么函数体 BlockStmt 查不到函数参数？因为函数作用域按官方设计关联到 FuncType，函数体块不是另一份函数作用域。需要分析参数时，应先找到函数声明对应的 FuncType 节点。

什么时候应该用 Package.Scope？当问题涉及包级声明、跨文件名称或预声明对象时使用它；Info.Scopes 更适合把一个具体 AST 节点映射到它定义的局部作用域。