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() 函数。
