Go服务启动慢主因是init()或main()开头执行I/O操作，应仅做纯内存初始化、用sync.Once懒加载非核心依赖，并通过CGO_ENABLED=0和-ldflags="-s -w"精简二进制及镜像。
init() 函数里做了 I/O 就注定启动慢，90% 的 Go 服务冷启动延迟都源于此——不是 Go 本身慢，而是你把
db.Ping()、
yaml.Unmarshal()、
http.Get() 这类阻塞操作塞进了不该放的地方。
别在 init() 里做任何带 I/O 或依赖的操作
init() 是同步、不可中断、按导入顺序串行执行的。一旦失败，进程直接退出，连日志都来不及打。
- 常见错误：在 config 包的
init() 里调 os.ReadFile("config.yaml")；在 db 包里调 sql.Open() + db.Ping()
- 正确做法：只放纯内存操作，比如
var statusMap = map[string]int{"ok": 1} 或注册无副作用的函数指针
- 排查方法：
go tool compile -S main.go | grep "CALL.*init" 快速定位哪些第三方包（如 goccy/go-yaml、zap）悄悄触发了重型初始化
用 sync.Once 实现安全的懒加载
延迟初始化不是“能晚就晚”，而是“首次用时才做，且只做一次”。
sync.Once 是标准库中最轻量、线程安全的方案。
- 别在
init() 里调 sync.Once.Do()——冗余，init() 本就是单次执行
- 内部不能含阻塞调用：如果
Do() 里写了没设 timeout 的 db.Ping()，所有并发首请求都会排队等它
- 生产建议返回 error 而非
log.Fatal()，避免无法 fallback：func GetDB() (*sql.DB, error) {
dbOnce.Do(func() {
d, err := sql.Open("mysql", os.Getenv("DSN"))
if err != nil {
dbErr = err
return
}
if err = d.Ping(); err != nil {
dbErr = err
return
}
db = d
})
return db, dbErr
}
CGO_ENABLED=0 和 -ldflags="-s -w" 是容器冷启动硬门槛
二进制太大、镜像太臃肿，代码再快也卡在加载阶段。
-
CGO_ENABLED=0 强制使用纯 Go DNS 解析和系统调用，避免 Alpine 镜像中 musl/glibc 不兼容导致的 exec user process caused: no such file or directory
-
-ldflags="-s -w" 去掉调试符号和 DWARF 信息，体积常减 30%–50%，对 Kubernetes 镜像拉取和 mmap 加载速度影响直接
- 基础镜像必须用
scratch 或 gcr.io/distroless/static，别用 alpine（除非真需要 nslookup）
- Dockerfile 必须多阶段构建：builder 阶段装 Go 环境，final 阶段只 COPY 二进制
Windows 下别信 go run 的耗时数据
go run 在 Windows 上慢是工具链问题，不是你的代码问题。它本质是“编译临时二进制 + 执行 + 清理”，每一步都受 NTFS + Defender 扫描拖累。
- 实测对比（Go 1.22，Windows 11）：
go run hello.go 耗时 4.2s；go build && ./hello.exe 仅 12ms
- 开发阶段请改用
go build -o app.exe && ./app.exe，或搭配 Air 等热重载工具
- 确保
GOMODCACHE 指向 SSD 路径，并关闭杀毒软件对 $GOPATH/pkg/mod 的实时扫描
- 升级到 Go 1.21+，其 Windows 构建器优化显著，
go run 平均提速 30–50%
真正影响启动速度的，从来不是
runtime.main 本身，而是你让 init 阶段承担了不该承担的事——比如第一次请求前就去连数据库、读几 MB 配置、预热缓存。这些动作只要挪到首次调用时，启动时间就能从秒级压到毫秒级。但要注意：懒加载不等于放任错误，
Do() 里的 panic 或未处理 error，会在第一次使用时才暴露，比 init 失败更难排查。
