Go 未显式赋值的包变量为什么不在 InitOrder 中

没有显式初始化表达式的包级变量不会出现在 types.Info.InitOrder 中，这是该字段的记录范围。变量仍按 Go 规则获得所属类型的零值；缺少列表项并不表示变量未初始化，也不表示类型检查漏掉声明。

我倾向于在分析报告里将“变量存在”与“需要记录初始化表达式”分成两个字段，否则一个空切片很容易被误读成“包里没有变量”。这里讨论的是 go/types 数据的含义，不依赖浏览器支持情况，也不需要执行被分析程序。

官方文档：https://pkg.go.dev/go/types#Info；零值规则：https://go.dev/ref/spec#The_zero_value。

列表记录的是初始化表达式

InitOrder 的元素是 Initializer，每项关联左侧变量对象与右侧 AST 表达式。没有表达式的声明不存在需要放入这份清单的右侧节点，因此不会生成对应记录。它不是包级变量总表，也不是初始化完成状态表。

例如 var A int 使用数值零值，var Cache map[string]int 使用 nil 零值。Cache 的 nil 不等于已创建可写 map；之后需要写入时，仍应按业务需求构造 map。列表是否包含 Cache，不改变这种语言语义。

用零值与显式零值作对照

关键对照是 var A int 与 var B = 0：两者初始值都是整数零，B 却有显式表达式。类似地，var Ptr *int = nil 也有显式表达式，即使结果为 nil。判断标准是声明形式，而非运行时的值是否为零。

下面的独立示例既读取 InitOrder，又从包作用域枚举具名变量，用对象身份关联两者。示例原创且未执行，不将文中的语义推导作为运行日志。

package main

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

func main() {
 // A 没有初始化表达式，B 则显式使用值为零的表达式。
 const source = `package sample
var A int
var B = 0
var Cache map[string]int
var Ptr *int = nil
`
 fset := token.NewFileSet()
 file, err := parser.ParseFile(fset, "sample.go", source, 0)
 if err != nil {
  fmt.Println("解析失败：", err)
  return
 }
 info := &types.Info{}
 conf := &types.Config{}
 pkg, err := conf.Check("example.com/sample", fset, []*ast.File{file}, info)
 if err != nil {
  // 不将检查失败后的部分信息当作完整清单。
  fmt.Println("类型检查失败：", err)
  return
 }
 explicit := make(map[*types.Var]bool)
 for _, initializer := range info.InitOrder {
  // 多变量初始化器需要登记全部左值对象。
  for _, variable := range initializer.Lhs {
   explicit[variable] = true
  }
 }
 scope := pkg.Scope()
 for _, name := range scope.Names() {
  variable, ok := scope.Lookup(name).(*types.Var)
  if !ok {
   continue
  }
  mode := "无显式初始化表达式"
  if explicit[variable] {
   mode = "包含显式初始化表达式"
  }
  fmt.Printf("%s (%s): %s\n", variable.Name(), variable.Type(), mode)
 }
}

完整变量清单应从包作用域取得

pkg.Scope().Names() 配合 Lookup 可以枚举包作用域中的具名对象，再用 *types.Var 类型断言筛出变量。这个作用域还可能包含常量、类型与函数，所以不能把所有名称直接当成变量。Names 的排列也不能当成初始化执行顺序。

示例以 *types.Var 为集合键，比单纯比较名字更适合表达同一次检查结果中的对象关联。若清单跨检查轮次缓存，不能假定不同轮次的对象指针仍相同；需要单独设计稳定标识。

这个方法覆盖包作用域的具名变量，不把结构体字段、局部变量或空白标识符当成同一类枚举目标。若要生成声明文档、保留空白标识符或逐条判断 ValueSpec 是否有 Values，应遍历顶层 AST 声明，并按需用 Info.Defs 关联声明对象，别把需求都塞给 InitOrder。

报告中保留两种数据的职责

我会保留原始 InitOrder 的顺序作为单独视图，在变量目录里只加“有无显式表达式”标注，不把零值变量硬插入切片。自行添加合成初始化器，会让读者无法区分官方结果与工具推导，后续维护也更难。

类型检查失败时不能仅凭缺少某一项就判断声明采用零值：错误后的结果可能不完整。示例先判断 Check 返回错误，再使用集合完成分类。真实项目还需确保加载的是目标构建所需文件，不能漏文件后归因于 API。

常见问题：InitOrder 为空是否有问题？只有零值声明的包可以正常出现这种情况。显式写等于零会被静态分析忽略吗？该字段按初始化表达式记录，不能用数值为零判断是否存在。是否包含 init 函数中的赋值？不包含；它也不记录变量在程序后续运行中的所有写入。