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 失败更难排查。
