Go InitOrder 为什么不同于源码文件的排列顺序

如果你用 go/types 做静态分析，看到的 Info.InitOrder 不是“按文件名从小到大排列的变量列表”。它先处理包级变量之间的初始化依赖：有依赖的变量按拓扑关系出现；互不依赖的变量才回到传入检查器的源码位置顺序。因此，源码文件的排列顺序只是没有更强依赖关系时的排序依据。

官方资料：https://pkg.go.dev/go/types#Initializer

本文做一个小型分析器，分别观察跨文件依赖和无依赖变量。这样你可以判断 InitOrder 的变化究竟来自依赖图，还是来自传给 types.Config.Check 的 AST 文件顺序。

先明确 InitOrder 到底表示什么

types.Info.InitOrder 是一组 *types.Initializer。每个初始化项包含左侧变量和右侧表达式，例如 var client = newClient(config) 会被记录为一个初始化关系。没有初始化表达式的包级变量不会出现在这个列表中。

它解决的是“包级变量应该按什么次序初始化”的静态分析问题，不是运行时日志，也不等于所有 init() 函数的调用列表。语言规范还规定，包级变量完成后才会调用包内的 init 函数。

准备一个最小的 go/types 分析器

分析入口需要三个对象：token.FileSet 管理位置，parser.ParseFile 把源码变成 AST，types.Config.Check 对整组文件做类型检查。要观察文件顺序，关键是保持源码内容不变，只交换传给 Check 的 AST 切片。

package main

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

type sourceFile struct {
	name string
	src  string
}

func analyze(files []sourceFile) error {
	fset := token.NewFileSet()
	asts := make([]*ast.File, 0, len(files))
	for _, file := range files {
		// 同一个 FileSet 让不同文件的位置可以放进同一套源码坐标。
		parsed, err := parser.ParseFile(fset, file.name, file.src, 0)
		if err != nil {
			return fmt.Errorf("parse %s: %w", file.name, err)
		}
		asts = append(asts, parsed)
	}

	info := types.Info{}
	conf := types.Config{}
	if _, err := conf.Check("demo", fset, asts, &info); err != nil {
		return fmt.Errorf("check package: %w", err)
	}
	for _, init := range info.InitOrder {
		// Initializer.String 会把左值和右侧表达式拼成便于阅读的摘要。
		fmt.Println(init.String())
	}
	return nil
}

func main() {
	files := []sourceFile{
		{name: "a.go", src: `package demo

var report = client
`},
		{name: "b.go", src: `package demo

var client = "ready"
`},
	}
	if err := analyze(files); err != nil {
		log.Fatal(err)
	}
}

这里的 report = client 产生了明确依赖，所以即使 a.go 在输入切片中先出现，client 也必须排在 report 前面。分析器只打印静态检查结果，不会执行这些变量初始化表达式。

有依赖时，InitOrder 为什么会先看拓扑关系

初始化依赖不是简单比较表达式文本的位置。Go 会分析初始化表达式以及其中引用到的当前包变量、函数和非接口方法，并把这些关系连成依赖图。依赖分析会传递：如果 report 引用了 buildClient，而 buildClient 的函数体又引用了 config，工具就应把 config 视作 report 的间接依赖。

因此上一段程序的结果应理解为：

client = "ready"
report = client

即使把两个文件的输入顺序反过来，只要依赖关系没有改变，client 仍然要先于 report。这正是 InitOrder 与“文件排列顺序”看起来不同的第一种原因。

没有依赖时，为什么又像是按文件顺序

再把两个变量改成互不引用：a.go 里只有 var first = "a"，b.go 里只有 var second = "b"。这时依赖图无法告诉分析器谁必须先做，InitOrder 会回到源码位置顺序。对多文件包来说，语言规范把文件传给编译器的顺序作为声明顺序的一部分，并建议构建系统按词法文件名顺序提供文件。

为了观察这一点，可以让分析器分别用两种输入顺序运行：

func main() {
	a := sourceFile{name: "a.go", src: "package demo\nvar first = \"a\"\n"}
	b := sourceFile{name: "b.go", src: "package demo\nvar second = \"b\"\n"}

	for _, files := range [][]sourceFile{{a, b}, {b, a}} {
		// 只交换 AST 输入顺序，源码内容和包名保持不变。
		fmt.Println("--- next check ---")
		if err := analyze(files); err != nil {
			log.Fatal(err)
		}
	}
}

这个实验的重点不是把它当作生产构建器，而是揭示排序契约：无依赖项的顺序会受源文件位置影响。正式工具如果需要可重复输出，应在解析前确定稳定的文件列表顺序，同时把这个约定写进工具文档。

把 InitOrder 用在源码工具中时要注意什么

不要把它当成 init 函数列表

InitOrder 关注的是包级变量初始化项；它不会替你枚举或排序包中的 init() 函数。需要解释运行时启动阶段时，应把“变量初始化”和“随后调用 init 函数”作为两个不同层次展示。

不要把没有出现在列表中的变量当成遗漏

零值声明如果没有初始化表达式，本来就不属于这个列表。工具界面可以把它标记为“无显式初始化”，但不要为了补齐列表而伪造一个初始化节点。

不要忽略隐藏依赖

规范明确指出，依赖分析基于词法引用；接口动态分派、外部状态或其他隐藏数据依赖不一定能被当前包分析发现。此时 InitOrder 仍是类型检查器能证明的顺序，不是所有运行时副作用的全局保证。

保留原始位置，展示时再做排序

建议同时记录 Initializer.Lhs 中变量的源位置和 Rhs 表达式。内部保留检查器给出的顺序，导出 JSON 或图形时再按用户选择展示“初始化顺序”“文件位置”两种视图，避免用二次排序破坏语义。

常见问题

为什么两个文件名排序后，InitOrder 还是不一样？

先检查传给 types.Config.Check 的 AST 文件切片是否真的按相同顺序构造，再检查变量之间是否有依赖。文件名本身不是 InitOrder 的唯一输入。

改变 a = b + c 为 a = c + b 会改变顺序吗？

仅交换同一初始化表达式中的子表达式顺序，不会改变依赖集合；只要其他条件不变，拓扑关系也不变。

InitOrder 能直接证明运行时一定没有副作用问题吗？

不能。它表达的是类型检查器识别到的当前包初始化依赖，接口调用、外部状态和隐藏依赖仍需单独设计和测试。

总结

解释 Go InitOrder 时记住一句话：先看依赖，依赖相同时再看源码位置。go/types.Info.InitOrder 把包级变量初始化表达成可消费的静态结果；文件顺序只在没有更强依赖关系时发挥作用。构建分析工具时固定 AST 输入顺序、保留源位置，并把变量初始化与 init() 调用分开呈现，就能避免把“源码排列”“依赖拓扑”和“运行时执行”混成一件事。