Go init函数执行顺序由编译器静态决定：跨包按依赖拓扑序（被依赖包先执行），同包按文件名Unicode字典序（如a.go早于b.go），同一文件仅允许一个init函数；试图用命名、注释或import顺序控制均不可靠，应改用显式Init()函数确保顺序与可测性。
Go 包初始化顺序无法“控制”，只能“顺应”或“规避”——依赖拓扑序和文件字典序是编译器静态决定的，任何试图靠命名、注释或 import 顺序来“安排” init 执行时机的做法，都会在重构或 CI 环境中失效。
同一包内不同文件的 init 执行顺序由文件名决定
go build 默认把同一包下的 .go 文件按文件名 Unicode 字典序传给编译器，因此 a.go 的 init 一定早于 b.go，01_db.go 早于 02_router.go。这不是巧合，而是当前 go 命令的稳定行为（Go 1.21+ 后更明确）。
- 若
a.go中init引用了b.go定义的全局变量dbConn，而b.go字典序靠后，dbConn就仍是零值，调用时直接 panic - 显式指定文件顺序（如
go build a.go c.go b.go）会覆盖默认字典序，导致init按 a → c → b 执行，这说明顺序本质由构建工具控制，而非语言保证 - 文件系统大小写敏感性（如 macOS vs Linux）理论上会影响字典序，但 go 命令内部统一用
strings.Compare，实际跨平台一致
同一文件里不能定义多个 init 函数
Go 编译器明确禁止：一个 .go 文件中出现多个 func init()，会报错 multiple init functions in file。这点常被误读——知识库中所谓“同一文件内多个 init 按声明顺序执行”是错误表述，实际语法不允许多个。
- 真正允许的是：一个文件里可有多个
var初始化表达式（含函数调用），它们在所有init函数之前求值 - 例如
var cfg = loadConfig()会在init()执行前调用loadConfig；但若loadConfig依赖另一个包的未初始化变量，仍可能 panic - 想分步初始化？别拆
init，改用普通函数，比如initDB()和initCache()，在单个init里按需调用
跨包 init 顺序只看直接 import 依赖链
包 A 的 init 是否在包 B 之前执行，唯一依据是 A 是否被 B 直接 import。间接依赖（A → B → C）不会触发 C 的 init，除非 C 也被显式 import。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
import _ "github.com/lib/pq"是为了触发其init注册驱动，但它必须出现在database/sql被使用之前，且不能被条件编译包裹（否则可能被优化掉） - 两个包无 import 关系（如
pkg/db和pkg/cache都被main导入），它们的init执行顺序未定义，每次go build都可能不同 - 循环 import（A import B，B import A）会导致编译失败，根本不会走到
init阶段——这是 Go 用编译期强制手段避免初始化歧义
真正可靠的初始化方式是显式 Init() 函数
当业务要求强顺序（如先连 DB、再加载配置、最后注册路由），必须放弃 init，改用可调用、可错误处理、可测试的普通函数。
- 各包提供
func Init() error，返回具体错误便于链式校验 - 在
main()开头按需调用：config.Init()→db.Init()→router.Init() - 用
sync.Once包裹逻辑，确保多次调用安全；或加状态字段防止重复初始化 -
init里不能recoverpanic，而显式函数可以包装defer/recover或重试逻辑
最易被忽略的一点：init 阶段 flag.Parse() 还没运行，os.Args 虽可用但命令行参数未解析；log 包自身已初始化，但自建日志若依赖未就绪的配置，也会 panic。这些边界不是“偶尔出问题”，而是每次启动都确定发生——只是你还没碰到那个环境。
