Go Info.InitOrder 怎样列出包级变量初始化依赖顺序

给类型检查传入非 nil 的 *types.Info，检查成功后按切片顺序遍历 info.InitOrder，即可列出当前包显式变量初始化器的顺序。每项的 Lhs 是被赋值的变量对象，Rhs 是初始化表达式 AST。不要再按变量名或源码行号排序，否则会破坏依赖关系决定的顺序。

官方文档：https://pkg.go.dev/go/types#Info；初始化器定义：https://pkg.go.dev/go/types#Initializer；语言规范：https://go.dev/ref/spec#Package_initialization。

准备完整的包级分析输入

这项分析的目标是生成包级变量初始化清单，不是启动程序，也不是跟踪 init 函数的运行。输入应包含当前构建中属于同一个包的源码文件，所有 AST 与检查器使用相应的 FileSet。真实项目的文件筛选、构建标签和依赖加载需要由上层包加载逻辑处理。

完整工作过程是准备源码与位置上下文、完成类型检查、读取初始化器、格式化表达式、输出清单。需要收集 InitOrder 时，可以直接使用空的 types.Info{}；这个字段是检查器生成的切片，不需要提前分配 map。若还要收集引用对象，则另行初始化相应的 Uses 等映射。

读取 InitOrder 并展示左右两侧

下面的独立示例包含前向引用、多返回值初始化、零值变量和 init 函数，便于区分哪些内容属于清单。示例不导入外部包，因此没有配置 Importer。代码仅用于说明，本文没有执行。

package main

import (
 "bytes"
 "fmt"
 "go/ast"
 "go/format"
 "go/parser"
 "go/token"
 "go/types"
 "strings"
)

func main() {
 // Total 写在 Base 前面，但初始化表达式引用了 Base。
 const source = `package sample
var Total = Base + 5
var Base = 12
var Left, Right = split()
var Empty int
func split() (int, int) { return 2, 3 }
func init() {}
`
 fset := token.NewFileSet()
 file, err := parser.ParseFile(fset, "sample.go", source, 0)
 if err != nil {
  fmt.Println("解析失败：", err)
  return
 }
 // InitOrder 是切片结果，无需像 Defs 那样预先创建 map。
 info := &types.Info{}
 conf := &types.Config{}
 if _, err := conf.Check("example.com/sample", fset, []*ast.File{file}, info); err != nil {
  // 检查失败时不把部分信息作为完整初始化方案。
  fmt.Println("类型检查失败：", err)
  return
 }
 for index, initializer := range info.InitOrder {
  names := make([]string, 0, len(initializer.Lhs))
  for _, variable := range initializer.Lhs {
   names = append(names, variable.Name())
  }
  var rhs bytes.Buffer
  // 将 AST 表达式格式化为可读文本，不求值、不执行函数。
  if err := format.Node(&rhs, fset, initializer.Rhs); err != nil {
   fmt.Println("表达式格式化失败：", err)
   return
  }
  pos := fset.Position(initializer.Rhs.Pos())
  fmt.Printf("%d. %s = %s (%s:%d)\n",
   index+1, strings.Join(names, ", "), rhs.String(), pos.Filename, pos.Line)
 }
}

一个初始化器不一定对应一个变量。Left, Right = split() 对应一次多值右侧表达式，读取时要保留完整 Lhs，不能把 split() 拆成两次调用。格式化 Rhs 只会把 AST 变成文字，不会执行被分析包中的函数。

解释依赖顺序与源码顺序

Total 的初始化表达式引用 Base，所以清单中 Base 应在 Total 之前，即使源码将 Total 写在前面。这个关系来自初始化依赖，不来自变量当前的值。初始化依赖相关的项按拓扑关系排列，不受依赖约束的项遵循源码顺序。

图中的 Total 与 Base 连线表示引用依赖，Left / Right 与 split() 连线表示初始化表达式归属；其他共同归属线不代表它们彼此依赖。切片的输出顺序应直接保留，而不是从图上的位置推断执行步骤。

跨多个文件时，提供给检查器的文件顺序会参与源码顺序的解释。工具应固定文件输入顺序，并与实际构建环境保持一致。仅将文件按文件系统返回的偶然顺序拼起来，会让没有依赖关系的条目缺少稳定的展示基础。

限定报告范围并处理失败

出现初始化循环或其他类型检查错误时，应先报告错误，不能把可能存在的部分信息包装成完整有效方案。示例在 Check 返回错误后直接退出，就是为了使输出的含义明确。需要错误容忍分析的工具，应给部分结果附加清晰状态，不能与成功清单混用。

推荐把每行保存为“序号、变量列表、右侧表达式、源码位置”，并保留原始初始化器关联。如果还要画每一条依赖边，需要额外做引用与依赖分析；InitOrder 本身是排序结果，不直接提供完整依赖图。分析函数体、方法引用等间接依赖时，也不能只扫描 Rhs 中出现的标识符就宣称覆盖了语言规则。

常见问题：空清单是否说明没有包级变量？不一定，可能只有无显式表达式的变量。能否用它计算初始化耗时？不能，它不执行表达式，也不记录耗时。它是否包含 init 函数？不包含，变量清单与函数初始化阶段应分别描述。