Go go/ast.Inspect 怎样定位资源未释放

go/ast.Inspect 没有需要调用的 Close，也不会替调用方关闭文件或清空节点缓存。遇到“遍历结束后资源没释放”，应先区分打开的文件是否关闭，以及回调保存的 AST 节点是否仍被引用。Inspect 只负责访问语法树，遍历结束不是资源所有权自动转移的时刻。

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

采用短作用域，让遍历只返回业务结果

设想一个按文件统计调用表达式的分析服务：请求持续到来，每次解析一个文件。如果最终只需要一个数值，比较简单的设计是把打开、解析、遍历放在短函数里，返回统计值，不返回整棵树。这个模式把文件关闭责任和业务数据保留范围放在同一处，便于判断对象应该活多久。

package analysis

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

func CountCalls(path string) (count int, err error) {
    f, err := os.Open(path)
    if err != nil {
        return 0, err
    }
    // 文件由本函数打开，因此成功、失败两种退出都安排关闭。
    defer func() {
        closeErr := f.Close()
        if err == nil {
            err = closeErr
        }
    }()
    tree, err := parser.ParseFile(
        token.NewFileSet(), path, f, parser.SkipObjectResolution,
    )
    if err != nil {
        return 0, err // 不把有语法错误的部分结果当成完整统计。
    }
    ast.Inspect(tree, func(n ast.Node) bool {
        if n == nil {
            return false // 这是遍历通知，不是资源释放信号。
        }
        if _, ok := n.(*ast.CallExpr); ok {
            count++ // 只留下数值，不把节点追加到长期容器。
        }
        return true
    })
    return count, nil
}

这是调用表达式的语法计数，不是运行时调用次数，也不解析最终调用目标。示例未在生产环境执行。parser.SkipObjectResolution 用于跳过已弃用的语法对象解析机制，不代表进行了类型检查。解析出错时立即返回，关闭错误只在前面没有错误时上报。

若在外层循环中反复打开文件，再将 defer Close 都挂到一个长期运行的函数里，句柄可能等到整个外层函数退出才关闭。用上面的短函数逐文件调用，可以让每份文件在本次处理完成时结束其作用域。反过来，如果 Reader 是外部传入的，是否关闭应写进接口约定，不能因为调用了 Inspect 就擅自关闭。

节点缓存是另一个生命周期

回调里把节点追加到全局切片、项目缓存或待处理队列，会让这些节点继续存活。保存一个复合节点，也可能通过它的子节点引用保留一片子树。不要笼统断言任何单个叶子节点都会保留整棵文件树；实际保留范围取决于节点字段和其他引用关系。

如果缓存的值同时装着 File、FileSet、源码切片或分析上下文，还应逐项判断这些字段是否必要。只保存文件名、位置整数和独立统计结果，通常比保存整个分析上下文更容易控制生命周期。需要长期源码片段时，应明确其是否与大型输入共享底层存储。

把局部变量 tree 设为 nil，不能解除缓存里的另一个引用。清空容器时也要关注底层存储：把一个装节点的切片长度改为零，不等于把底层数组中的所有节点引用都置空。若确实要继续复用容器，应对自己拥有的旧元素解除引用；如果直接舍弃整个容器，则应确保其他地方没有继续持有它。

返回 false 和收到 nil 都不是关闭协议

Inspect 采用深度优先访问。回调针对某个非空节点返回 false，表示不再向下访问该节点的子树，并不表示所有兄弟节点都停止，也不会触发外部资源关闭。若要找到目标后避免进一步处理，需由回调共享状态表达“已找到”，后续访问再据此剪枝；不要把局部剪枝误当成函数返回。

当某个节点的回调返回 true 时，其子节点访问结束后会有对应的 nil 通知。它表示一次遍历层级的收尾，不是整个文件完成的统一通知。将文件 Close 放在 nil 分支，可能在遍历仍进行时关闭，甚至反复关闭。文件生命周期应留在资源所有者的函数作用域中。

同样，在每次节点回调里 defer 一个关闭动作，该 defer 属于这一次回调调用；回调返回就会执行。它不会自动延后到整棵树遍历结束。如果每个节点真的需要临时资源，应让一次节点处理完整拥有它；若资源跨多个节点共享，就放在遍历外层管理。

这个设计会带来什么取舍

返回值越精简，跨请求保留的树结构越少，但重复分析可能需要再次解析。需要交互式跳转、增量分析的工具可以保留 AST，不过应为缓存明确项目范围、过期策略和容量。保留树是业务选择；没有生命周期边界的无限增长，才是需要优先修正的设计。

判断修复是否符合目标时，应分别看句柄生命周期、缓存条目数量与结果正确性。进程内存没有立刻下降，并不能单独证明文件没有关闭；对象可达性、垃圾回收和内存归还并不是同一件事。

相关问题

Inspect 会自动创建 goroutine 吗？标准库实现通过同步遍历调用回调。若回调自行启动 goroutine，任务结束、引用捕获和并发写入要由回调的调用方另行管理。

为什么删掉根节点变量还会占内存？可能仍有其他缓存或闭包持有相关对象。应检查实际保存了哪些引用，而不是只处理根变量。

只需要诊断位置，还要保存节点吗？可以考虑在遍历时提取独立的文件名、行列与诊断文本，返回简化结果；若要随后再查询 AST，则需要保留相应分析数据并管理其生命周期。

参考：Inspect 接口说明、ParseFile 参数约定、遍历实现。