Go packages.Load 怎样加载指定文件集的包信息

使用默认 Go 构建工具时，可将同一目录下的若干个 .go 文件路径作为独立参数传给 packages.Load(cfg, files...)，加载由这些文件组成的临时包。如果目的是根据某个文件找到它原本所属的完整包，应改用 file=路径 查询。两种输入的语义不同，不能互相替换。

官方地址：https://pkg.go.dev/golang.org/x/tools/go/packages

先确定是文件集合，还是文件所属的包

假设一个分析工具收到 a.go 和 b.go。它可能要研究“仅由这两个文件构成的代码”，也可能要研究“这两个文件所在的工程包”。我会先把这项选择放到入口参数里，因为后续再补类型信息，也无法纠正起点选错造成的包范围差异。

这里的文件列表语义以默认 Go 工具为前提；外部 GOPACKAGESDRIVER 的模式解释应以该驱动为准。也不要将多个文件名拼成一个带空格的字符串：Load 接收的是可变参数列表，而不是待 shell 拆分的命令行。

用同目录文件列表构造一次加载

下面的封装明确只接受目标目录直属的非测试 Go 文件。相对文件名基于传入的 dir 解析，并统一为绝对路径；这样工具进程从哪里启动，不会隐式改变这些文件名的含义。

package inspect

import (
    "context"
    "fmt"
    "path/filepath"
    "strings"

    "golang.org/x/tools/go/packages"
)

// LoadSelected 加载同一目录中的显式 Go 文件集合，不自动补入同目录其他文件。
func LoadSelected(ctx context.Context, dir string, names []string) ([]*packages.Package, error) {
    if len(names) == 0 {
        return nil, fmt.Errorf("必须指定至少一个 Go 文件")
    }
    base, err := filepath.Abs(dir)
    if err != nil {
        return nil, fmt.Errorf("解析工作目录: %w", err)
    }
    files := make([]string, 0, len(names))
    for _, name := range names {
        path := name
        if !filepath.IsAbs(path) {
            path = filepath.Join(base, path)
        }
        path = filepath.Clean(path)
        // 本例只接受目录直属的普通 .go 文件；路径比较不解析符号链接。
        if filepath.Dir(path) != base || filepath.Ext(path) != ".go" ||
            strings.HasSuffix(path, "_test.go") {
            return nil, fmt.Errorf("不支持的文件: %s", name)
        }
        files = append(files, path)
    }
    cfg := &packages.Config{
        Context: ctx,
        Dir: base,
        Mode: packages.NeedName | packages.NeedFiles | packages.NeedCompiledGoFiles,
    }
    pkgs, err := packages.Load(cfg, files...)
    if err != nil {
        return nil, fmt.Errorf("加载调用失败: %w", err)
    }
    if len(pkgs) == 0 {
        return nil, fmt.Errorf("没有加载到包")
    }
    // err 为空并不表示每个包都没有诊断；此处把诊断汇总给调用方。
    var diagnostics []string
    for _, pkg := range pkgs {
        for _, issue := range pkg.Errors {
            diagnostics = append(diagnostics, pkg.ID+": "+issue.Error())
        }
    }
    if len(diagnostics) > 0 {
        return pkgs, fmt.Errorf("包诊断: %s", strings.Join(diagnostics, "; "))
    }
    return pkgs, nil
}

例如 names 可以是 []string{"a.go", "b.go"}，dir 指向这两个文件的目录。文件仍需真实存在、包声明兼容，所需模块和依赖也应可由项目构建环境解析。此处路径限制只是一个简化的输入约定，未解析符号链接，不应拿来充当不可信文件访问的隔离机制。

显式文件集合不会自动加入同目录的 c.go。如果 a.go 引用了只在 c.go 中定义的对象，后续需要类型信息时就可能暴露缺失定义。对于正常工程分析，我倾向于加载完整目录包；对于有意研究不完整文件组合的任务，才保留文件列表入口。示例没有执行记录，也不附带某个工程的真实加载输出。

按需求选择包信息的详细程度

Config.Mode 决定返回信息的范围。本例只要包名、源文件列表和适合类型检查的文件列表，因此显式组合 NeedName、NeedFiles、NeedCompiledGoFiles。没有请求类型或语法信息，就不能把相应字段为空解释为源码没有声明。

需要已检查的语法树时，可以考虑 LoadSyntax；若还需要依赖包的完整语法信息，再评估 LoadAllSyntax。官方文档说明，获取更多信息的模式通常会更慢。我不会仅为了打印包 ID，就把整个依赖图的类型与语法全部载入。

GoFiles 与 CompiledGoFiles 也不应混为一谈：前者是包的 Go 源文件路径，后者是适合类型检查的源文件路径，遇到预处理等情形可能不同。工具应根据所消费的数据选择字段，而不是把两个列表直接拼接。

同时处理调用错误和包内诊断

Load 的返回 error 用于调用或模式等层面的失败；与具体包有关的问题通常进入 Package.Errors，并不会必然令返回 error 非空。示例把这两种情况分别处理，同时将诊断发生时已经取得的包返回，方便上层决定是否展示不完整信息。

这种设计不是要求所有工具遇到诊断就退出。只显示名称的浏览器与依赖完整类型信息的检查器，可以采取不同策略。但界面或报告必须说明结果是否完整，不能在拿到若干 Package 对象后就标成“全部分析成功”。LoadMode 没有要求的检查也不会因为读取了 Errors 就自动执行。

把文件选择封装在分析入口

我更愿意把文件选择、工作目录、加载模式和诊断策略封装成同一个分析入口。调用方提供用户选择，入口确定分析范围，下游只处理本次返回的包对象。这样比在不同检查规则里各自调用 Load 更容易维持一致的上下文。

代价是入口必须清楚区分两种能力：精确文件集与工程所属包。若将它们隐藏在同一个“加载文件”按钮后，就容易出现同一工具在不同入口得到不同包范围的问题。涉及类型信息时，还要避免混用多次 Load 调用产生的类型对象；官方文档提醒它们具有各自的类型身份体系。

常见问题：file= 只加载那个文件吗？不是，它查询包含该文件的包。可以随意把不同目录的文件组成一个包吗？默认 Go 文件列表要求同一目录，本例也主动限制。err 为空是否代表代码正确？不代表，应结合包诊断与请求的 Mode 判断。只需要解析孤立代码片段时是否一定要 Load？不一定，若完全不需要包、模块或类型上下文，可评估更直接的语法解析 API。

指定文件集加载的关键不在参数数量，而在明确这些路径究竟是在定义一个临时包，还是在定位原有工程包。把这个约定写清，再按需求请求字段，调用结果才容易解释。

参考：go/packages 官方文档；Go 文件列表规则。