go语言中init函数执行顺序：跨包按依赖拓扑序，同包按文件名unicode字典序，同一文件内按源码自上而下顺序；该顺序由编译器静态分析确定，非import语句或书写位置决定。
init() 的执行顺序不是靠 import 语句或代码书写位置决定的，而是由编译器静态分析包依赖图 + 文件名排序共同确定的；跨包按依赖拓扑序，同包按文件名字典序，同一文件内按源码出现顺序。
同一包内多个 init 函数怎么按文件名执行
Go 编译器把同一包下的所有 .go 文件按文件名 Unicode 字典序（lexicographic order）排序后传入，然后依次执行每个文件里的 init 函数。比如 01_config.go、db.go、router.go 会按此顺序执行，而不是按 go build 命令里写的参数顺序。
- 默认行为稳定：即使在不同操作系统上，
go build内部用strings.Compare排序，不依赖底层文件系统遍历顺序 - 显式指定文件顺序会覆盖字典序：
go run b.go a.go会让b.go的init先跑，输出b然后a - 不要依赖字典序做逻辑耦合：如果
a.go的init用了b.go声明的var db *sql.DB，而b.go字典序靠后，db就是nil，调用时直接 panic - 推荐做法：用数字前缀强制排序（如
01_db.go、02_http.go），或干脆合并到一个文件里
同一文件里多个 init 函数怎么执行
一个 .go 文件可以定义多个 func init()，它们严格按源码从上到下出现的顺序执行，且不能互相调用（语法报错）。
- 变量初始化表达式（如
var port = os.Getenv("PORT")）在本文件所有init之前执行 - 但若该表达式调用了其他包函数（比如
config.Load()），而 config 包还没初始化，仍会 panic - 常见误判：以为“写在后面的 init 就后执行”，其实只看声明位置，不看函数名或注释
- 调试建议：在每个
init开头加log.Println("init A")，运行时看输出顺序就能验证
跨包 init 为什么总在依赖包之后执行
编译器构建包依赖图，按拓扑序执行 init：被导入的包一定先完成初始化，当前包才开始。比如 import "net/http" 的包，net/http.init 必然在它自己的 init 之前跑完。
-
import _ "net/http/pprof"也会触发 pprof 包的init，且它发生在当前包任何变量声明和init之前 - 循环 import（A→B→A）直接编译失败，根本不会走到
init阶段 - 间接依赖不自动触发：A 导入 B，B 导入 C，但 A 没直接 import C，则 C 的
init不一定执行——除非 A 显式引用了 C 的导出符号 - 标准库如
fmt、os的init是安全的，但自定义包若在init里调用log.Printf，得确认 log 包已完成初始化
init 里访问跨包变量为什么容易 panic
因为 Go 不保证未显式 import 的包已初始化，也不保证跨包全局变量在你访问时已完成赋值。哪怕 import 了，只要依赖链断裂（比如靠反射、字符串拼接访问），变量就还是零值。
- 典型 panic 场景：
db.QueryRow报nil pointer dereference，根源是db所在包的init没执行 -
os.Args在init里可用，但flag.Parse()还没调，别指望命令行参数已解析 - 空白导入（
import _ "github.com/lib/pq"）只为触发驱动注册，如果漏掉，sql.Open("postgres", ...)会报unknown driver - 最稳妥方式：把初始化逻辑封装成普通函数（如
SetupDB()），在main开头显式调用，可控、可测试、可 debug
真正难处理的不是顺序本身，而是隐式依赖——你以为“都 import 了就万事大吉”，结果某个包因未被符号引用而跳过初始化，panic 却出现在十行之外的另一处调用点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
