同一文件内可写多个init函数，按源码从上到下的声明顺序依次执行；不同文件间按文件名字典序执行；跨包则依导入依赖链递归初始化，且仅限直接import的包。
init 函数不是“自动初始化方法”，而是包加载时的隐式钩子；它早于 main、不可调用、不接受参数，且执行时机不受你控制——想靠它读配置、连数据库、等 flag 解析，基本会失败。
同一文件里能写几个 init？按什么顺序执行？
可以写多个，但必须在同一个 .go 文件内；它们按源码从上到下的声明顺序依次执行。编译器不报错，也不合并，更不会优化掉。
- 先写的
init一定先执行，后写的一定后执行，和函数名、注释、空行都无关 - 如果两个
init都修改同一个全局变量（比如config.Port），后者会覆盖前者 - 调试时建议加日志：
log.Println("db.go init #1")，避免依赖fmt.Println被缓冲导致看不到输出
不同文件的 init 执行顺序由什么决定？
Go 编译器按文件名的字典序（ASCII）遍历并执行，不是按 import 语句顺序，也不是按创建时间或 import 位置。
-
01_config.go的init一定在router.go之前，z_util.go会排到最后 - 别靠改文件名“控制顺序”：这会让重构脆弱，团队协作混乱，且不是语言规范保证的行为
- 真正可靠的只有包级依赖顺序——比如
import "net/http"，则net和http包的所有init一定在当前包之前完成
为什么在 init 里调 flag.Parse() 或读 os.Getenv 常静默失败？
因为 init 运行时，命令行参数虽已存在（os.Args 可读），但 flag 包内部状态尚未就绪，环境变量也可能未被 shell 完全展开，而配置路径、数据库地址等关键输入根本还没解析出来。
-
flag.String("port", "8080", "")在init中取值永远是默认值，flag.Parse()一调就 panic -
os.Getenv("DB_URL")可能返回空字符串，尤其在容器或 systemd 环境下，变量加载时机晚于init - 错误堆栈只显示
runtime.main，无法定位到具体哪行init出问题，也recover不了
哪些操作绝对不该放进 init？
任何带副作用、阻塞、依赖运行时输入或跨包状态的操作，都会让启动变得不可控、不可测、不可调试。
- 启动 HTTP server：
http.ListenAndServe会永久阻塞，卡死整个初始化流程 - 连接数据库/Redis：
sql.Open不会立即连，但db.Ping会超时失败，且无日志可查 - 读大配置文件：
os.ReadFile("config.yaml")路径错、权限不足、格式非法时直接 panic，没机会提示用户 - 调其他包函数：
log.SetOutput看似安全，但如果它内部依赖本包未初始化的字段，照样 panic
最常被忽略的一点：测试时 init 会被执行两次（单元测试框架 + go test 主流程），资源重复初始化极易引发端口占用、文件锁冲突等问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
