Go应用启动慢八成因init()和main()前半段初始化时机失控；用time.Now()打点、go tool trace和pprof可精准定位DNS解析、DB连接、锁竞争等卡点。
Go 应用启动慢，八成问题出在 init() 和 main() 前半段——不是代码写得差，而是初始化时机没控住。直接上分析手段，别等上线后靠猜。
用 time.Now() 打点定位耗时模块
最轻量、最可靠的方式：在关键初始化步骤前后插入时间戳，不依赖任何工具链，立刻看到哪一步卡住。
- 把
time.Now()放在真正逻辑开始前，比如配置解析函数入口、DB 连接池创建前，而不是main()第一行——否则参数校验失败或 panic 会导致time.Since()返回 0 或负值 - 避免嵌套记录：不要用
time.Since(dbStart)去算“后续步骤”，每个阶段独立记起点：dbStart := time.Now()、cacheStart := time.Now() - 输出建议带上下文，例如
log.Printf("[startup] load config: %v", time.Since(start))，方便 grep 过滤 - 注意：容器环境下（尤其 CPU 被 cgroup 限频的 Pod）
time.Since()波动可能变大，这不是测量误差，是真实调度延迟
启用 go tool trace 查看 goroutine 阻塞源头
go tool trace 能暴露 init 阶段哪些 goroutine 在等系统调用、锁、网络或 GC，比日志更底层。
- 启动时加
-trace=trace.out：运行go run -trace=trace.out main.go，程序退出后生成 trace 文件 - 重点看 “Goroutines” 视图里
main.init和runtime.main时间线，找长时间处于runnable或syscall状态的 goroutine - 常见卡点：DNS 解析（
net.Resolver.LookupHost）、os.Open读配置文件、sql.Open后首次Ping()、第三方库在init()里调远程配置中心 - 若 trace 显示大量 goroutine 卡在
semacquire1，说明有锁竞争——但启动期一般不该出现，大概率是某个全局 sync.Mutex 在init()里被提前争抢了
检查 init() 是否触发了隐式阻塞操作
Go 的 init() 是隐式串行执行的，一个慢，全队列等。很多库会悄悄在这里埋雷。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 用
go list -f '{{.Imports}}' .检查依赖树，重点关注含net/http、database/sql、os/user、crypto/tls的包——它们的init()可能做 DNS 查询、证书加载、用户信息解析 - CGO_ENABLED=0 编译后仍卡住？可能是用了
net包的纯 Go DNS 解析器（net.DefaultResolver），它会在首次解析时读/etc/resolv.conf并尝试连接 nameserver - 第三方 SDK（如 Sentry、Datadog）常在
init()里自动上报版本或建立连接，务必查其文档，关掉 auto-init 或延迟到main()后 - 自己写的
init()函数里，禁止出现：http.Get、os.ReadFile（大文件）、time.Sleep、sync.Mutex.Lock（除非已知无竞争）
用 pprof 抓启动期 CPU 和 Mutex 竞争
如果打点和 trace 还看不出瓶颈，说明耗时分散在大量小操作里，需要采样级分析。
- CPU profile：启动时加
runtime.SetCPUProfileRate(1e6)（微秒级），并在main()开头调用pprof.StartCPUProfile，几秒后StopCPUProfile；注意别在init()里开，那时 pprof handler 还没注册 - Mutex profile：必须在
main()最开头（甚至早于日志初始化）调用runtime.SetMutexProfileFraction(5)，否则/debug/pprof/mutex为空；生产环境别设为 1，5～10 就够定位热点 - 分析时用
go tool pprof -lines mutex.pprof强制展开到行级，再focus=YourStruct\.mu过滤具体锁字段——别信默认聚合，sync.Mutex.Lock会被所有锁混在一起 - 若 profile 显示大量时间花在
runtime.mallocgc或runtime.scanobject，说明启动期分配太多临时对象，考虑复用sync.Pool或预分配 slice
启动耗时分析最难的不是工具不会用，而是你得先承认：那些写在 init() 里的“方便逻辑”，大概率就是罪魁祸首。越早把它挪走，越早看清真实瓶颈在哪。
