Go程序启动慢主因是包级变量和init()函数中的I/O操作；应避免包级初始化、改用懒加载、构建标签隔离冷依赖、静态链接优化。
全局变量初始化会阻塞启动流程
Go 程序在进入 main 函数前，必须完成所有包级变量初始化和 init() 函数调用。如果某个全局变量的初始化表达式包含 I/O 操作（如读配置文件、解析 YAML、加载证书），整个启动过程就会卡在那里——哪怕这个变量只在程序运行 5 分钟后才第一次被用到。
常见现象：go run main.go 耗时 400ms+，pprof 显示大量时间花在 os.Open 或 yaml.Unmarshal 上，而这些调用都来自包级变量声明行。
- 错误写法：
var cfg = loadConfigFromFile("config.yaml")—— 导入该包即触发读盘 - 正确方向：改为
func GetConfig() *Config，首次调用时才加载 - 注意：
loadConfigFromFile若内部用了http.Get或redis.NewClient，问题会更隐蔽
第三方包的 init() 是隐形性能杀手
你没显式调用任何函数，但只要 import "github.com/go-sql-driver/mysql"，它的 init() 就会执行——可能注册驱动、设置默认日志器、甚至尝试连接数据库（某些封装库真这么干）。
这类初始化不是“按需”，而是“按导入”，且无法跳过。更麻烦的是，它还会触发其依赖包的初始化链，比如 mysql → crypto/tls → net → os/user，每一步都可能带出额外 I/O 或系统调用。
- 排查方法：
go list -f '{{.Deps}}' . | tr ' ' '\n' | sort -u | grep -E "(sql|redis|http|yaml|toml)" - 典型冗余依赖：
gopkg.in/yaml.v2启动时反射开销大，换成gopkg.in/yaml.v3可降 30–50ms - 冷功能别打包进来：监控模块用
//go:build with_metrics隔离，编译时加-tags with_metrics控制
跨包变量依赖导致初始化顺序不可控
看似安全的跨包引用，比如 var A = B + 1（A 在包 a，B 在包 b），实际初始化顺序由构建时的依赖图决定。若 b 包因其他导入被提前初始化，B 正常；若 b 被延迟，A 就会用到 B 的零值（0），结果 A=1 而非预期的 3——这种 bug 只在特定构建环境或交叉编译（macOS vs Linux）下复现。
- 根本问题：Go 不保证跨包变量的初始化先后，只保证“被导入包先于导入包”
- 陷阱示例：
import "myapp/config"触发 config 包初始化，而 config 包里又import "myapp/db"，db 包的全局*sql.DB初始化可能早于 config 的DBURL变量 - 解法不是加 log，而是切断直接依赖：用
func Init(cfg Config)显式传参，把初始化时机收归main
sync.Once 和 atomic.Value 不解决“首次初始化谁先谁后”问题
很多人以为用 sync.Once 就能绕过初始化顺序问题，其实它只保证“同一个变量的初始化只执行一次”，不解决“多个全局变量之间谁该先准备好”。比如两个单例 db 和 cache 都用 sync.Once，但 cache 初始化时依赖 db，若 cache 的 Do 先被触发，db 还是 nil。
-
sync.Once必须是指针类型：var once *sync.Once = new(sync.Once)，否则副本失效 -
atomic.Value不能替代sync.Once：它只保读写原子性，不保“首次赋值唯一性” - 真正可控的方式：在
main中按需顺序调用InitDB()→InitCache()，把控制权拿回来
init() 函数。 
