init函数执行顺序由编译器严格约束：跨包按依赖拓扑序，同包按文件名Unicode字典序，同一文件内按源码从上到下文本顺序；不可显式调用、不可互相调用，且变量初始化先于init执行。
init 函数不是你写完就能按预期跑起来的“初始化入口”，它执行时机固定、顺序受编译器严格约束，且一旦出错很难调试。别指望靠多写几个 init 就能控制启动流程——它只响应依赖图和文件名，不听你指挥。
同一文件里多个 init 函数怎么执行
一个 .go 文件里可以定义多个 func init()，它们按源码中出现的**文本顺序**从上到下执行，和函数名、注释、空行完全无关。
- 先声明的
init一定先执行，后声明的一定后执行 - 不能在
init里调用另一个init（语法报错：undefined: init） - 如果后一个
init依赖前一个初始化的包级变量，逻辑上合理；但若反过来——后声明的init赋值，前声明的init读取——就会读到零值 - 调试时建议加日志，比如
log.Println("config init #1")，避免依赖fmt.Println被缓冲导致顺序错乱
不同文件的 init 执行顺序由文件名决定
Go 编译器对同一包下的所有 .go 文件，按文件名 Unicode 字典序（不是创建时间、不是 import 顺序、不是 go build 命令参数顺序）排序后依次执行其中的 init 函数。
-
01_db.go一定早于app.go，而z_router.go几乎总在最后 - macOS 和 Linux 下行为一致，因为
go工具链内部用strings.Compare排序，不依赖文件系统遍历 - 常见翻车：在
a.go的init中直接使用b.go声明的var db *sql.DB，但b.go字典序靠后 →db是nil，调用db.Ping()直接 panic - 数字前缀（如
01_config.go、02_service.go）是临时 workaround，但重构时极易断裂；更稳妥的做法是把强依赖逻辑合并进一个文件，或改用显式函数
跨包导入时 init 的触发顺序不看 import 行
Go 不按 import 语句书写顺序执行跨包 init，而是按**依赖拓扑序**：被导入的包（如 pkg/config）一定先于导入它的包（如 pkg/server）完成 init。
-
import _ "github.com/lib/pq"是为了触发其init注册 SQL 驱动，但它必须出现在database/sql实际使用之前，且不能被条件编译包裹（否则可能被优化掉） - 如果
main.go同时import "pkg/db"和import "pkg/cache"，两者无相互 import，则它们的init执行顺序未定义——每次构建都可能不同 - 循环 import（哪怕只是
import _）会导致编译失败，错误信息类似import cycle not allowed，根本走不到init阶段 - 间接依赖不会自动触发
init：A 导入 B，B 导入 C，但 A 没直接 import C，则 C 的init不保证执行——除非 A 显式引用了 C 的导出符号
init 里哪些操作大概率失败
init 是包加载阶段的临界区，所有操作必须无副作用、不阻塞、不依赖运行时输入。但开发者常在这里做数据库连接、配置解析、flag 读取等高风险操作。
立即学习“go语言免费学习笔记（深入）”；
-
os.Getenv("DB_URL")可能返回空字符串——环境变量还没被 shell 加载完毕，或go run未透传 -
flag.String("port", "8080", "")定义后不调flag.Parse()，该变量永远是默认值；而flag.Parse()必须在main里调用，init阶段根本不可用 -
http.ListenAndServe()会永久阻塞，导致后续init和main都无法执行 -
sql.Open()可能因网络超时、认证失败而返回 error，但init里没法 recover 或重试，程序直接 crash - 调用其他包的导出函数（如
log.SetOutput），而该函数内部又依赖它自己包的未初始化变量，造成隐式依赖链断裂
init 拆出来，变成显式的、可测试、可控制顺序的函数调用——比如 SetupDB()、LoadConfig()，并在 main 开头手动调用。这不是放弃便利性，而是把控制权从编译器手里拿回来。最容易被忽略的点是：**变量初始化表达式（如 var port = os.Getenv("PORT")）在本文件所有 init 之前执行**，但它若调用了其他包函数，依然可能因依赖未就绪而 panic。 
