Go程序启动慢主因是init()或main()开头执行I/O操作，应改用sync.Once懒加载、静态编译减体积、GODEBUG=netdns=go优化DNS解析。
Go 程序启动慢，90% 是因为把本该懒加载的逻辑塞进了 init() 或 main() 开头——这些操作不光拖时间，还让首请求变卡、健康检查失败、K8s 启动探针超时。
别在 init() 里做任何带 I/O 或依赖的事
init() 函数会在 main() 前自动、同步、不可中断地执行。一旦里面调了 db.Ping()、os.ReadFile()、http.Get()，整个进程就得干等，失败直接退出，连日志都来不及打。
- 常见错误现象：
go run main.go很快，但构建后的二进制启动要 5 秒以上；pprof热点全在runtime.main → init调用栈里 - 典型踩坑：
zap.NewProduction()在init()里调用——它默认启用 JSON 编码 + 时间格式化 + 调用栈捕获；本地调试请换zap.NewDevelopment() - 第三方库也要查：
go tool compile -S main.go | grep "CALL.*init"可快速定位哪些包悄悄干了重活（比如某些 YAML 解析器或 ORM 的反射扫描）
用 sync.Once 实现安全的懒加载
延迟初始化不是“能晚就晚”，而是“首次用时才做，且只做一次”。sync.Once 是 Go 标准库里最轻量、线程安全的方案，比自己加 sync.RWMutex 判断更可靠。
- 正确写法示例：
var ( dbOnce sync.Once db *sql.DB ) func GetDB() *sql.DB { dbOnce.Do(func() { d, err := sql.Open("mysql", os.Getenv("DSN")) if err != nil { log.Fatal(err) // 生产建议返回 error，而非 fatal } db = d }) return db } - 性能影响：首请求多一次判断开销（纳秒级），但换来的是启动瞬间完成；后续调用完全零成本
- 注意陷阱：别在
Do里做阻塞调用（如没设 timeout 的db.Ping()），否则所有并发首请求都会排队等它
CGO_ENABLED=0 和 -ldflags="-s -w" 是容器启动提速的硬门槛
很多 Go 容器启动慢，根本原因不是代码，而是二进制和镜像本身不干净：动态链接 libc、带调试符号、基础镜像臃肿。
-
CGO_ENABLED=0强制使用纯 Go 实现（包括 DNS 解析），避免 Alpine 镜像里因 musl/glibc 不兼容导致exec user process caused: no such file or directory -
go build -ldflags="-s -w"去掉符号表和 DWARF 调试信息，二进制体积常减少 30%–50%，对 Kubernetes 镜像拉取和 mmap 加载速度影响直接 - 基础镜像选
scratch或gcr.io/distroless/static，别用alpine（除非你真需要nslookup或 musl 特性） - Dockerfile 必须用多阶段构建：builder 阶段装 Go 编译环境，final 阶段只
COPY二进制
识别和剥离冷启动时的冗余依赖
Go 的链接器不会自动剔除未使用的符号，但「导入即使用」的惯性会让很多功能模块在启动时被拉进来——哪怕你只调用了其中 1 个函数。
- 典型场景：主程序
import了github.com/spf13/cobra，但只用它注册子命令；结果cobra又间接import了golang.org/x/sys/unix和一堆终端检测逻辑，全在启动时跑一遍 - 用
go list -f '{{.Deps}}' . | tr ' ' '\n' | sort -u列出所有依赖，人工排查非核心路径（如net/http/httputil、image/png） - 对可选功能做构建标签隔离：比如监控模块用
//go:build with_metrics，编译时加-tags with_metrics控制是否加载 - 替换重型依赖：用
gopkg.in/yaml.v3替代v2（v2启动时反射开销大）；用fasthttp替代net/http（若你不需要标准库 HTTP 全功能）
真正难的不是写对 sync.Once，而是判断哪些初始化必须前置、哪些可以后置——比如证书加载若用于 TLS listener，就必须在 main() 启动 server 前完成；而 Redis 连接池完全可以等到第一个缓存请求到来时再建连。这个边界，得结合业务 SLA 和失败容忍度来划。
