Go types.Scope.Lookup 为什么找不到外层变量

types.Scope.Lookup 只查当前作用域自己的声明，不向父作用域搜索。内层块能使用外层变量，并不意味着外层变量会被复制进内层符号表。需要沿词法作用域查找时，使用 LookupParent(name, pos)；已经完成类型检查且手上有使用处的 *ast.Ident 时，优先从 Info.Uses 取得它绑定的对象。

我在阅读这类分析代码时，会先把“这个块声明了什么”和“这里能引用什么”分开。前者是查表，后者涉及父作用域、遮蔽和声明生效位置；把两个问题混在一起，最容易把正常的 nil 当成解析失败。

官方地址：https://pkg.go.dev/go/types

Lookup 的边界是一个符号表

设 outer 声明 shared，它的子作用域 inner 声明 local。此时 inner.Lookup("local") 能找到本层对象，inner.Lookup("shared") 返回 nil。后一个结果只表示当前表中没有该名字，并没有否定父层声明。

inner.Parent() 是结构上的外层关联。Lookup 不自动使用这条关联；LookupParent 才把它纳入查询语义。判断当前表有哪些声明，可以查看 Names()，不要预期其中包含全部可见名字。

先用最小片段分清本层查询与父层查询

下面手工建立两个作用域，用来说明 API 差异，不涉及源码解析，也不代表已经在本机执行过的结果。无位置信息的人工模型使用 token.NoPos，不要据此推导真实源码中的声明时序。

package main

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

func main() {
    // 手工模型只展示包含关系，不模拟真实源码的生效位置。
    outer := types.NewScope(nil, token.NoPos, token.NoPos, "outer")
    inner := types.NewScope(outer, token.NoPos, token.NoPos, "inner")
    shared := types.NewVar(token.NoPos, nil, "shared", types.Typ[types.Int])
    local := types.NewVar(token.NoPos, nil, "local", types.Typ[types.Int])

    // Insert 返回已有同名对象；这里把名称冲突视为构造错误。
    if old := outer.Insert(shared); old != nil {
        panic("外层名称重复")
    }
    if old := inner.Insert(local); old != nil {
        panic("内层名称重复")
    }

    fmt.Println("仅查本层是否找到：", inner.Lookup("shared") != nil)
    // NoPos 不按源码位置筛选声明，适合本段人工关系模型。
    owner, obj := inner.LookupParent("shared", token.NoPos)
    fmt.Println("父层查询是否找到：", obj != nil)
    fmt.Println("是否来自外层：", owner == outer)
}

按接口语义，第一项判断应为 false，后两项应为 true。这是示例的预期判断，不是采集的执行日志。实际项目若仍找不到对象，下一步应检查作用域来源及查询位置。

需要语言语义时，把使用位置一起交给查询

真实分析器不能只取得一个任意作用域就开始查名字。LookupParent 从调用接收者开始沿父链查找，不会向子作用域搜索。若从包作用域出发查函数局部变量，即使它确实存在于语法树中，也不会被找到。

类型检查时初始化 Info.Scopes 和 Info.Uses，解析与检查共享同一套 FileSet。已知使用处标识符时，info.Uses[id] 直接给出绑定对象；只有按名字做探索性查询时，再选取包含使用点的词法作用域并调用 LookupParent。

// 此片段放入已有 AST 与类型检查流程，不是独立 main 程序。
info := &types.Info{
    Scopes: make(map[ast.Node]*types.Scope),
    Uses:   make(map[*ast.Ident]types.Object),
}
conf := types.Config{}
_, err := conf.Check("example.local/demo", fset, []*ast.File{file}, info)
if err != nil {
    // 有错误时先保留诊断；下面只处理检查成功的完整语义信息。
    return err
}

// id 必须来自上面这份 AST，并且是使用处而非声明处。
obj := info.Uses[id]
if obj == nil {
    return fmt.Errorf("该节点没有已解析的使用对象")
}
// 若已经掌握正确的词法作用域 s，也可按名字和使用位置查询。
_, byName := s.LookupParent(id.Name, id.Pos())
_ = byName

片段中的 ast、fmt、types 分别来自 go/ast、fmt、go/types；file、fset、id 和 s 是调用方已经取得的输入。示例包不含导入声明；有导入时，还需为检查器配置合适的 Importer。

遮蔽、位置和 nil 分别说明什么

内外层同名时，父链查询首先匹配离起点最近的有效声明。如果内层对象在查询位置尚未进入作用范围，带有效 pos 的查询会考虑声明位置；传 token.NoPos 则不做该位置限制。因此，编辑器的光标查询与人工符号表演示不宜机械地使用相同参数。

位置必须属于类型检查时的 AST 和 FileSet。把行号直接转成 token.Pos，或者混入另一份解析结果中的位置，会让范围判断失去依据。需要结合子作用域选起点时，可在已经包含目标位置的适当祖先作用域上使用 Innermost(pos)；结果也可能为 nil，应先处理再调用查询。

我会怎样选择最终写法

做“本层声明列表”时，我保留 Lookup 的局部边界；做名称补全或位置查询时，我使用正确起点上的 LookupParent；做引用跳转时，我倾向于复用 Info.Uses，避免重新拼装一次名字解析。取舍取决于任务，而不是把所有 nil 都用遍历父节点掩盖掉。

把外层对象再 Insert 到内层能解决吗？

不建议。那会改变符号表模型，也可能干扰遮蔽判断。要表达可见性，应使用已有父链。

LookupParent 返回的作用域就是 obj.Parent() 吗？

通常一致，但点导入对象可能例外：查找命中的作用域与对象原本所属包的作用域并非一回事。需要知道命中位置时，使用返回的第一个结果，不要直接替换为对象的 Parent。

声明节点为什么在 Info.Uses 中找不到？

声明与使用属于不同记录。声明处应根据任务查看 Info.Defs；不要把不适用的映射入口当成外层变量丢失。