go中init函数执行顺序明确：同一文件内按源码从上到下执行，同一包不同文件按文件名unicode字典序执行，跨包按依赖拓扑序执行；它不可显式调用、不接受参数、无返回值，且必须避免运行时依赖以防止启动panic。
Go 里 init 函数不是你写完就能按预期跑的“初始化入口”，它是一套由编译器静态决定、运行时强制执行的隐式机制——你无法显式调用，也不能控制其跨包顺序，稍不注意就会在启动瞬间 panic。
同一文件里多个 init 怎么执行？
一个 .go 文件中可以定义多个 func init()，它们严格按源码中出现的**从上到下文本顺序**执行。这不是约定，是编译器硬性规则。
- 不能互相调用（语法报错）
- 所有
init共享包级作用域，但变量初始化（如var port = os.Getenv("PORT")）发生在所有init之前 - 如果某个
initpanic，后续同文件的init不再执行，整个程序终止 - 常见误判：把函数名写成
initDB、initLog，以为能靠命名暗示顺序——编译器完全忽略
同一包下不同文件的 init 执行顺序
Go 编译器把同一包所有 .go 文件按**文件名 Unicode 字典序**排序后依次加载，然后执行每个文件里的 init。比如 01_config.go → db.go → z_router.go。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 这个顺序与
go build命令参数无关，也不看文件创建时间或 import 行位置 -
a.go的init引用了b.go声明的var db *sql.DB，但b.go字典序靠后 →db还是nil，调用即panic - 用数字前缀（如
01_db.go）是常见 hack，但它只是利用当前实现，不是语言保证；重构时一旦改名就失效 - 更稳妥的做法：强依赖逻辑合并进单个文件，或干脆不用
init，改用显式函数
跨包 init 为什么总不按 import 顺序走？
Go 不按 import 语句顺序触发 init，而是构建包依赖图后按**拓扑序**执行：被直接 import 的包（如 pkg/config）一定先于依赖它的包（如 pkg/server）完成 init。
- 间接依赖不参与排序：A → B → C，但 A 没直接
import C，则C.init()可能根本不执行 -
main包的init总是最后，因为它不被其他包 import -
import _ "github.com/lib/pq"必须出现在database/sql.Open("postgres", ...)之前，否则驱动未注册，报错sql: unknown driver "postgres" - 循环 import（哪怕只用
import _）会导致编译失败，错误类似import cycle not allowed
为什么在 init 里连数据库或读环境变量常失败？
因为 init 是包加载临界区，要求操作必须无副作用、不阻塞、不依赖运行时输入——而数据库连接、os.Getenv、flag.String 全都不满足。
-
os.Getenv("DB_URL")在init里返回空字符串？可能是因为os包自身还没完成初始化，或者环境变量在构建镜像时未注入 -
flag.String("port", "8080", "")在init里永远拿不到命令行值，因为flag.Parse()在main里才调用 - 绝对不该做：
http.ListenAndServe（永久阻塞）、sql.Open（可能超时/认证失败）、os.ReadFile（路径错或权限不足时静默失败） - 真正安全的做法：把初始化逻辑拆成显式函数，如
config.Load()、db.Connect()，并在main中按需顺序调用
最易被忽略的一点：你写的每个 init 都在和编译器赛跑——它不等你，也不解释为什么失败。一旦涉及跨文件变量访问、第三方包函数调用、或任何运行时依赖，问题就从“逻辑错误”变成“启动即崩”。别把它当初始化工具箱，它只是 Go 构建系统的一道闸门，开合时机由依赖图和文件名决定，而不是你的意图。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
