init()函数拖慢服务启动是因为其在main()前串行执行且易含耗时操作；应改用lazy init（如sync.Once+error返回）并仅在首次使用时初始化，非关键逻辑可延至首请求前。

为什么 init() 函数会拖慢服务启动

Go 程序在 main() 执行前会同步执行所有包的 init() 函数，且按导入依赖顺序串行执行。一旦某个 init() 里做了耗时操作（比如连接数据库、读取大配置文件、生成 RSA 密钥对），整个启动流程就被卡住。

常见误用场景包括：

• 在 config/ 包的 init() 中直接调用 os.ReadFile("app.yaml") 并解析
• 在 db/ 包的 init() 中调用 sql.Open() + db.Ping()
• 在 crypto/ 包的 init() 中调用 rsa.GenerateKey()

这些操作应推迟到首次使用时（lazy init），或明确由 main() 控制时机。

如何识别启动瓶颈：用 go tool trace 定位耗时阶段

Go 自带的 trace 工具能可视化启动过程中的 goroutine 调度、系统调用和阻塞点，比手动打日志更可靠。

实操步骤：

• 编译时加 -gcflags="all=-l" 禁用内联（避免函数被优化掉，影响 trace 可读性）
• 运行程序时设置环境变量：GOTRACEBACK=crash GODEBUG=schedtrace=1000（辅助观察调度）
• 用 go run -gcflags="all=-l" main.go & PID=$! 启动后立即采集：go tool trace -pprof=exec -duration=2s -timeout=5s ./myapp $PID

重点关注「Startup」时间段内的灰色阻塞条（GC、syscalls、network I/O），它们通常对应 init() 或 main() 开头的同步初始化。

sync.Once 和 lazyloading 的正确组合方式

延迟加载不是简单套个 sync.Once 就完事——必须确保初始化函数不暴露副作用、不阻塞主线程、且可重入安全。

典型错误写法：

var db *sql.DB
var once sync.Once

func GetDB() *sql.DB {
    once.Do(func() {
        db = sql.Open(...) // ❌ 这里没检查 err，也没 Ping()
        db.Ping()          // ❌ 如果失败，panic 会静默吞掉，后续调用直接 panic nil pointer
    })
    return db
}

推荐写法：

var (
    db   *sql.DB
    once sync.Once
    err  error
)

func GetDB() (*sql.DB, error) {
    once.Do(func() {
        db, err = sql.Open("postgres", os.Getenv("DSN"))
        if err != nil {
            return
        }
        err = db.Ping()
    })
    return db, err
}

关键点：

• 返回 error，让调用方决定是否 panic / fallback / retry
• 把 err 提升为包级变量，避免重复分配
• 不在 init() 中触发 once.Do，只在业务 handler 第一次访问时触发

配置热加载 vs 启动加载：别把 runtime 逻辑塞进 startup

很多团队把 YAML 解析、结构体绑定、校验全放在启动期做，结果一个 2MB 的配置文件解析要 300ms。其实只要配置不参与路由注册、中间件链构建等真正需要启动时确定的逻辑，完全可以懒加载。

适用懒加载的配置项：

• HTTP client timeout、重试次数
• 缓存 TTL、最大连接数
• 特征开关（feature flags）的默认值

不建议懒加载的配置项：

• 监听地址（http.ListenAndServe(addr, mux) 需要它）
• 证书路径（TLS config 构建必须存在）
• 数据库 DSN（如果路由初始化依赖 DB 连接池）

折中方案：启动时只读取并校验关键字段（如 server.addr, tls.cert），其余字段用 sync.Once + map[string]interface{} 按需解析。

启动速度优化最常被忽略的一点：不是“怎么更快”，而是“哪些根本不用在启动时做”。很多服务把健康检查探针、指标上报、日志轮转策略都提前到 init()，但其实它们只需要在第一个请求到来前就绪即可——这个时间窗口往往有几百毫秒，足够完成大部分非关键初始化。