Go服务冷启动慢主因是init()中执行db.Ping()等阻塞操作，应移至main()或用sync.Once懒加载并设timeout，同时精简镜像、关闭调试、剥离冷依赖。
init()里调了db.Ping()就别想快启动
Go服务冷启动慢，90%是因为把db.Ping()、os.ReadFile()、http.Get()这类阻塞操作塞进了init()函数。它在main()前同步串行执行，失败直接退出，连日志都来不及打。
- 典型错误：config包的
init()里解析YAML；db包里sql.Open()后立刻db.Ping() - 本地
go run main.go快，是工具链跳过了部分初始化；构建后的二进制会严格执行全部init()，暴露真实瓶颈 - 用
go tool compile -S main.go | grep "CALL.*init"能快速定位哪些第三方库（比如goccy/go-yaml或zap.NewProduction()）悄悄干了重活 -
init()只该放纯内存操作：如var statusMap = map[string]int{"ok": 1}，或注册无副作用的函数指针
用sync.Once做懒加载，但别写错
延迟初始化不是“能晚就晚”，而是“首次用时才做，且只做一次”。sync.Once是标准库最轻量、线程安全的方案，但内部不能含阻塞调用——否则所有并发首请求都会排队等它。
- 错误写法：
dbOnce.Do(func() { d, _ := sql.Open(...); d.Ping() })—— 没设timeout，网络卡住就全堵死 - 正确姿势：返回
error而非log.Fatal()，让调用方决定是否fallback或重试 - 首请求有纳秒级判断开销，换来的是启动瞬间完成；后续调用零成本
- 别在
init()里调sync.Once.Do()——冗余，init()本就是单次执行
编译参数和镜像选型是硬门槛
代码再快，二进制太大、镜像太臃肿，容器冷启动照样卡在加载阶段。这不是应用层能优化的，得从构建命令和Dockerfile动手。
- 必须加编译参数：
CGO_ENABLED=0（避免musl/glibc不兼容报exec user process caused: no such file or directory），go build -ldflags="-s -w"（去符号表+调试信息，体积常减30%–50%） - 基础镜像必须用
scratch或gcr.io/distroless/static-debian12，别用alpine（除非真需要nslookup） - Dockerfile必须多阶段构建：builder阶段装Go环境，final阶段只
COPY二进制文件 - 镜像体积从几百MB压到几十MB后，Kubernetes拉取+解压+
mmap加载速度提升明显
startupProbe和健康检查接口要独立设计
健康检查不能依赖业务初始化完成。Kubernetes的startupProbe若配置不当，会误杀还没ready的服务；而/healthz如果和DB连接强耦合，就绪时间就被拖长。
-
startupProbe.initialDelaySeconds设为3~5秒，给足够缓冲，避免刚启动就被kill -
/healthz应只返回进程存活状态（alive），不检查DB/Redis等下游依赖；下游健康状态走/readyz单独暴露 - 数据库连接失败不应导致进程退出，而应记录日志，并由
readinessProbe反馈状态，配合K8s探针实现弹性恢复 - 非核心依赖（如缓存预热、远程配置加载）移到后台goroutine异步执行，用
context.WithTimeout控制超时，避免阻塞主线程
init()里那行db.Ping()正在同步等三次握手，也不是你写的HTTP handler慢，而是镜像里多塞的那100MB Alpine libc正在被Kubelet mmap加载。 
