Go go/ast.Inspect 为什么在边界输入上得到空结果

Go go/ast.Inspect 得到空结果，通常不是遍历器失效。先查四件事：parser.ParseFile 是否报错、传入的根节点是否有效、回调是否在父节点上返回了 false，以及输入 AST 里是否真的存在你要统计的节点类型。对只有 package 子句的合法源码，统计函数声明当然会得到 0；而回调把根节点剪掉时，整棵子树也不会再访问。

官方文档：https://pkg.go.dev/go/ast#Inspect

另外，Inspect 的回调会收到 nil 作为一个遍历收尾信号。它不是 AST 节点，不能拿来计数，也不能用“收到过 nil”证明输入为空。

先确认输入真的包含目标节点

ast.Inspect 从传入的根节点开始深度优先遍历。最容易误判的一种情况，是源码本身合法，但结构比预期简单：只有包名时，AST 里有文件节点和包名标识符，却没有 FuncDecl、CallExpr 或声明列表。此时如果业务代码只统计函数声明，结果为 0 正是正确结果。

package main

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

func main() {
    // 只有包子句的源码是合法的边界输入，但其中没有函数声明。
    src := "package demo"
    f, err := parser.ParseFile(token.NewFileSet(), "demo.go", src, parser.SkipObjectResolution)
    if err != nil {
        // 解析失败时不要把一个空计数当成“遍历没有结果”。
        panic(err)
    }

    funcs := 0
    ast.Inspect(f, func(n ast.Node) bool {
        // 只统计函数声明；包名和文件节点不会进入这个计数。
        if _, ok := n.(*ast.FuncDecl); ok {
            funcs++
        }
        return true // 继续访问当前节点的非空子节点。
    })
    fmt.Println("函数声明数量：", funcs)
}

这个例子的结果是 0，但遍历并没有“空跑”：回调仍然会看到根文件节点和包名标识符。真正需要确认的是业务目标——你是在统计所有节点、标识符，还是只统计函数声明。统计对象越窄，合法输入得到 0 的可能性越高。

回调返回 false 会让整棵子树停止访问

官方契约规定：Inspect 先调用 f(node)，只有当回调返回 true 时，才会继续访问该节点的非空子节点。如果在根节点、文件节点或某个声明节点上返回 false，后续节点自然不会出现。

package main

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

func main() {
    // 输入中确实有函数，但根节点被主动剪枝，函数仍然不会被访问。
    src := "package demo; func Run() {}"
    f, err := parser.ParseFile(token.NewFileSet(), "demo.go", src, 0)
    if err != nil {
        panic(err) // 先处理语法错误，避免把错误输入当成空结果。
    }

    funcs := 0
    ast.Inspect(f, func(n ast.Node) bool {
        if _, ok := n.(*ast.File); ok {
            return false // 根节点不下沉，整棵文件子树都被跳过。
        }
        if _, ok := n.(*ast.FuncDecl); ok {
            funcs++
        }
        return true
    })
    fmt.Println("函数声明数量：", funcs)
}

这个例子仍会输出 0，但原因已经不同：不是输入缺少函数，而是根回调返回了 false。排查时可以临时在回调开头记录节点类型，先确认根节点是否进入，再看哪个分支改变了返回值。不要只把回调中的计数器移到别处，否则仍然看不出剪枝发生在哪一层。

f(nil) 不是一个空 AST 节点

Inspect 底层复用了 Walk 的访问协议。一个节点的回调返回 true 后，所有非空子节点处理完毕，遍历器会再调用一次 f(nil)。因此同一个回调既会处理真实节点，也会处理离开子树的收尾信号。

如果代码没有先判断 n == nil，就直接做类型断言、读取位置或访问字段，可能出现空指针问题；如果代码把 nil 当成“没有遍历到节点”，又会把正常的收尾过程误判为空结果。稳妥的做法是把两类职责分开：

ast.Inspect(f, func(n ast.Node) bool {
    if n == nil {
        // nil 表示当前子树访问结束；这里只做清理，不参与业务计数。
        return true
    }

    switch node := n.(type) {
    case *ast.FuncDecl:
        // 真实函数节点才进入业务统计。
        fmt.Println("函数：", node.Name.Name)
    case *ast.CallExpr:
        // 调用表达式是另一类真实节点，按需要单独处理。
        fmt.Println("调用表达式")
    }
    return true // 默认继续遍历，特殊分支再明确剪枝。
})

这里的 nil 处理只表达遍历生命周期，不会让结果多出一个节点。若需要维护当前路径或嵌套层级，可以在进入真实节点时压栈，在收到 nil 时出栈；若只需要顺序访问非空节点，也可以考虑较新的 ast.Preorder 迭代器，避免自己处理收尾信号。

把“空结果”拆成四种可定位的情况

尤其要把“解析失败”和“合法但没有目标声明”分开。parser.ParseFile 返回错误时，调用方应先处理错误；只有拿到合法的 *ast.File 后，才适合讨论遍历结果。反过来，如果源码只有包名，解析成功且目标声明数为 0，就不需要为它寻找版本回归。

一套不容易误判的排查顺序

1. 先打印或记录 ParseFile 的错误，不要用计数器代替错误处理。
2. 确认传入 Inspect 的根节点不是 nil，并说明输入是文件、声明还是表达式。
3. 临时只返回 true，排除回调剪枝造成的空结果。
4. 对回调参数先做 nil 判断，再记录 %T 或使用类型分支。
5. 确认输入里真的存在目标节点；如果要统计函数，至少准备一个带函数声明的源码样本。
6. 最后再恢复业务筛选和路径状态，把“没有命中”解释成输入边界、剪枝或条件不匹配中的一种。

如果要同时保留父节点路径，Inspect 的 nil 收尾回调可以维护栈，但必须保证每次入栈都有对应出栈；如果只想顺序消费非空节点，优先选择 Preorder。这两种选择都不能替代对解析错误和输入结构的检查。

相关问题

传入 nil 根节点会返回空结果吗？不会把它当成普通空树处理。官方契约要求 node 不能为 nil；调用前应确保解析成功并拿到有效节点。

为什么回调里统计 Ident，却看不到函数名？常见原因是回调在父节点提前返回 false，或实际统计的是另一个 AST 根节点。先确认函数声明确实在当前输入中，再检查返回值。

收到 f(nil) 后是否应该停止遍历？nil 是收尾信号，通常只用于清理路径状态。不要用它替代业务节点判断；是否继续由回调的返回值协议决定。

Inspect 和 Preorder 该怎么选？需要控制子树下沉、维护进入/离开状态时使用 Inspect；只需要按深度优先顺序获得非空节点时，Preorder 更直接。

参考：go/ast.Inspect 官方文档、Go 官方 ast/walk.go 源码。本文只围绕回调语义、输入结构和筛选边界解释空结果，不把合法的 0 命中包装成遍历器故障。