Init() 无法解决组件启动顺序问题，因其执行时机早于运行时依赖确定、不可控且无错误处理与上下文支持；应改用带依赖拓扑排序的 Start()/Stop() 生命周期接口。
为什么 Init() 不能解决组件启动顺序问题
Go 的 init() 函数在包加载时执行，但它的调用顺序仅由导入依赖图决定，无法表达“数据库连接就绪后才启动 HTTP 服务”这类运行时依赖。多个组件都依赖 database/sql 包时，init() 执行顺序不可控，容易出现 panic: sql: database is closed 或空指针解引用。
真正需要的是运行时可干预的生命周期钩子，而非编译期静态初始化。
-
init()没有参数、不能返回错误、无法重试，也不支持上下文取消 - 组件间依赖关系往往在配置解析后才明确（比如从 YAML 读出 DB 地址），此时
init()早已执行完毕 - 测试环境下常需跳过某些组件（如不启 Kafka），但
init()无法条件跳过
用 Start() 和 Stop() 接口统一管理组件生命周期
定义一个最小接口比引入复杂框架更直接：
type Lifecycler interface {
Start(ctx context.Context) error
Stop(ctx context.Context) error
}
每个组件（DB client、gRPC server、Redis pool、消息消费者）实现该接口，并在 Start() 中做连接建立、健康检查、资源预热等操作。
立即学习“go语言免费学习笔记（深入）”；
- HTTP server 的
Start()应监听端口前先调用db.PingContext(ctx)，失败则返回错误，不继续启动 - 所有
Start()调用必须串行，且按依赖拓扑排序（例如：DB → Cache → API Server） - 避免在
Start()中启动 goroutine 后立即返回——这会让调用方误以为组件已就绪；应等待监听器真正 accept 连接或收到第一个心跳响应
依赖拓扑排序必须手动编码，不要依赖反射或注解
Go 没有运行时类型依赖图，所谓“自动排序”通常靠字符串匹配组件名或硬编码优先级字段，极易失效。真实项目中应显式声明依赖：
type Component struct {
Name string
Start func(context.Context) error
Stop func(context.Context) error
Requires []string // 依赖的组件名，如 []string{"db", "redis"}
}
启动时用 Kahn 算法做拓扑排序，遇到环状依赖（如 A→B 且 B→A）直接 panic 并打印完整路径，而不是静默忽略。
- 不要用
reflect扫描结构体字段找Requires——字段名拼错或导出规则不符就会漏依赖 - 配置文件里写
depends_on: ["db"]是陷阱：YAML 解析后是字符串切片，没做校验就传给排序逻辑，会导致启动时 panic - 测试时可通过传入空依赖列表快速绕过依赖检查，但生产环境必须校验所有
Requires名称是否对应已注册组件
context.Context 超时和取消必须贯穿整个启动链
单个组件启动卡住（比如 PostgreSQL 连接超时），不能让整个服务 hang 死。所有 Start() 必须接受并传递 ctx，并在阻塞操作中使用带超时的变体：
- 用
ctxhttp.Do替代http.DefaultClient.Do，确保 HTTP 健康检查受 ctx 控制 - 数据库连接用
sql.Open+db.PingContext(ctx)，而不是sql.Open后单独 goroutine ping - gRPC server 的
srv.Serve(lis)不要直接调用——它会阻塞，应在Start()中启动 goroutine 并监听ctx.Done()来触发lis.Close()和srv.GracefulStop()
最易被忽略的是：主函数里启动组件的循环本身也要设超时，否则某个组件 Start() 返回慢，后续组件永远等不到执行机会。
