Go types.Scope 怎样按源码位置查询最近的声明

按源码位置找最近的可见声明，可以先用包作用域的 Innermost(pos) 取得查询起点，再调用 LookupParent(name, pos)。这里的“最近”指词法层级上首先命中的可见对象，不是文件里离光标字符距离最短的同名声明。位置必须来自本次解析使用的 FileSet。

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

把查询拆成位置和词法层级

这类能力适合源码浏览器、变量提示和静态分析工具。它不需要新框架：go/parser 负责得到 AST，go/types 负责建立语义信息。在准备调用前，应明确三项输入：哪个包、哪个名称、源码的哪个位置。

不能直接拿包作用域查询函数里的局部变量。LookupParent 只沿起点的父链查找，不会替调用者搜索所有子作用域。先定位最内层作用域，才有机会考虑当前位置附近的局部遮蔽。普通 Lookup 则只检查当前作用域，也没有位置参数。

准备一段具有同名声明的源码

示例让包级和局部声明都叫 value。函数内先读取包级值，再执行 value := value + 1，最后读取局部值。初始化右侧的 value 与声明左侧虽然很近，却不表示同一个绑定。这比单独列出一个方法签名更能说明位置参数的用途。

下面是完整程序。它只分析内嵌字符串，不执行 sample 函数；类型检查遇到错误会结束。文中的判断是示例设计预期，并非本机实测输出。

package main

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

// 示例源码中，局部变量初始化右侧仍引用包级 value。
const source = `package sample
var value = 10
func sample() {
    _ = value
    value := value + 1
    _ = value
}
`

func main() {
    // 解析与类型检查必须共用 FileSet，保证位置属于同一坐标系。
    fset := token.NewFileSet()
    file, err := parser.ParseFile(fset, "sample.go", source, 0)
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        return
    }
    info := &types.Info{Uses: make(map[*ast.Ident]types.Object)}
    conf := types.Config{}
    pkg, err := conf.Check("example/sample", fset, []*ast.File{file}, info)
    if err != nil {
        // 本例遇到类型错误就停止，避免把不完整信息当成可靠绑定。
        fmt.Fprintln(os.Stderr, err)
        return
    }

    ast.Inspect(file, func(node ast.Node) bool {
        id, ok := node.(*ast.Ident)
        if !ok || id.Name != "value" || info.Uses[id] == nil {
            return true
        }
        // 先选择包含使用位置的最内层作用域，再查询父链。
        scope := pkg.Scope().Innermost(id.Pos())
        if scope == nil {
            fmt.Println("没有包含该位置的作用域")
            return true
        }
        foundScope, obj := scope.LookupParent(id.Name, id.Pos())
        if obj == nil {
            fmt.Println("未找到可见声明")
            return true
        }
        // 同时保留命中作用域和声明位置，便于工具显示与定位。
        fmt.Printf("使用位置=%s 声明位置=%s 命中作用域=%p 与Uses一致=%t\n",
            fset.Position(id.Pos()), fset.Position(obj.Pos()),
            foundScope, obj == info.Uses[id])
        return true
    })
}

从最内层作用域查询并保留命中位置

程序先把源码使用位置交给 Innermost，再把同一位置交给 LookupParent。前一个调用选择词法范围，后一个调用在这个范围及祖先中筛选可见对象。两者承担不同职责，不能因为查询有 pos 参数就省略作用域选择。

按这段源码的语义，第一次读取和局部初始化右侧应关联包级 value，最后一次读取应关联局部 value。观察时比较声明位置即可，不应把作用域指针地址当成固定输出。实际打印的路径、行列和地址由解析输入及进程决定。

如果把位置换成 token.NoPos，就失去了位置筛选条件，不能再把查询结果解释为“这个光标处可见”。同时，不要自行用 obj.Pos() 与查询位置比较来替代类型系统的作用域规则；声明标识符的位置与名称开始可见的位置不总是一回事。

区分位置查询和既有标识符绑定

返回的 foundScope 表示在哪个作用域查到了名称，obj 才是语义对象。做跳转时可用 obj.Pos() 定位声明；做可见名称分析时应保留 foundScope。涉及点导入等情形，不能无条件认定返回作用域就是 obj.Parent()。

如果手里已经有一个通过类型检查的使用标识符，通常直接读取 info.Uses[id] 更明确。LookupParent 则适用于“在这个位置询问某个名字”的任务，例如用户尚未写完名称时的词法查询。本例把两者放在一起，是为了显示已有标识符的绑定与位置查询的关系，不能推广成所有语法位置都只靠名称查询完成。

接入工具时保留这些边界

编辑器给出的行列不能直接强制转换成 token.Pos。应先对照同一份文件内容定位字节偏移，再通过该文件对应的 token.File 得到位置。编辑后重新解析时，也要重新建立配套的语义信息，避免拿旧 AST 的位置查询新包。

多文件包应在同一次类型检查中提供相关文件；涉及导入时，还需配置与项目环境相符的导入处理。真实项目不能把此处无导入、单文件的例子当成完整加载器。类型错误恢复、构建条件和未保存文件内容也应在工具层明确处理。

为什么查询得到 nil？

先看位置是否属于当前文件集合，再看 Innermost 是否选到了作用域，最后区分名称确实不可见与类型信息不完整；不要直接改成忽略位置查询。

能查结构体字段或方法吗？

词法名称查询不能直接替代选择器解析。x.Field 或 x.Method 还涉及接收者类型等语义，应使用相应类型信息和选择器分析能力。

手工创建 Scope 能复现所有可见性规则吗？

不能把手工 Insert 的对象表等同于完整类型检查的作用域。教学和工具接入都应优先使用与源码一致的类型检查结果。

进一步阅读：https://go.dev/src/go/types/scope.go。接入时最关键的是保持源码、位置和语义信息来自同一轮分析，再根据任务选用位置查询或已记录的标识符绑定。