Go语言中import会触发初始化，因为所有导入包（含空白导入）都会在程序启动前按依赖拓扑序自动执行其init函数及包级变量初始化，这是编译期确定的强制行为，旨在保证初始化的确定性与可预测性。
Go 语言没有运行时“按需 import”机制，所有 import 语句在编译期就确定并强制初始化。所谓“延迟加载”，实际是延迟执行初始化逻辑，而非跳过包加载。
为什么 import 就会触发初始化？
Go 的每个包都有隐式 init() 函数，只要该包被 import（哪怕用的是 _ "xxx"），其 init() 就会在程序启动时、main() 之前执行——连带它依赖的所有包也会递归初始化。比如只写 import _ "crypto/x509"，就会拉入 bytes、crypto/sha256、encoding/pem 等十多个包，二进制体积和启动耗时都会上升。
这不是 bug，是 Go 的设计选择：确定性、可预测的初始化顺序，代价是无法真正“跳过”未使用的包。
- 用
go build --ldflags=--dumpdep main.go 2>&1 | grep inittask可直观看到哪些包被拖进来了 - 标准库中像
net/http这种“表面轻量、背后庞大”的包，尤其容易成为隐性依赖源 - 第三方包若在
init()里做网络请求或磁盘读取，会直接卡住整个启动流程
sync.Once 是延迟执行初始化逻辑的唯一可靠方式
你不能阻止包被加载，但可以阻止它的昂贵操作被执行。核心是把初始化动作从 init() 或全局变量赋值中抽出来，封装成函数，再用 sync.Once 包裹。
立即学习“go语言免费学习笔记（深入）”；
典型错误写法：
var db *sql.DB = connectDB() // 启动即连接，不可控
正确做法：
var (
db *sql.DB
once sync.Once
)
<p>func GetDB() *sql.DB {
once.Do(func() {
db = connectDB() // 真正连接只发生第一次调用时
})
return db
}
-
sync.Once保证即使一百个 goroutine 同时调用GetDB()，也只执行一次connectDB() - 别在
once.Do里做可能失败的操作（如网络请求）后不保存错误——否则下次调用仍会重试；应把 error 存为全局变量或返回给调用方 - 不要用
if db == nil+ 手动加锁替代sync.Once，易出竞态且代码冗长
第三方包怎么“假装没引入”？靠接口抽象 + 延迟构造
如果你只在某些路径下才用到某个重型第三方包（比如 PDF 生成、图像处理），又不想让它污染所有场景的启动时间和二进制体积，就得靠接口解耦 + 运行时构造。
例如，你有个服务需要偶尔导出 PDF，但 99% 的请求不需要：
type PDFGenerator interface {
Generate(data map[string]interface{}) ([]byte, error)
}
<p>// real.go（仅在需要时才被链接进最终二进制）
type pdfGen struct{}
func (p <em>pdfGen) Generate(...) { /</em> 调用 github.com/jung-kurt/gofpdf */ }</p><p>// proxy.go（始终存在，轻量）
type LazyPDF struct {
gen PDFGenerator
once sync.Once
}
func (l *LazyPDF) Generate(data map[string]interface{}) ([]byte, error) {
l.once.Do(func() {
l.gen = &pdfGen{} // 此时才真正引用 gofpdf 包
})
return l.gen.Generate(data)
}
- 关键点：
gofpdf只出现在real.go文件里，且该文件只有在构建包含 PDF 功能的版本时才参与编译（可通过//go:build pdftag 控制） - 如果必须全量构建，就把
pdfGen的构造逻辑放进once.Do，确保包虽被加载，但重型初始化被推迟 - 避免在接口实现里嵌入第三方结构体（如
struct{ *gofpdf.Pdf }），这会让编译器把整个包符号拉进来
Agollo、Viper 这类配置库的延迟加载是怎么回事？
它们的“延迟加载”不是跳过 import，而是把配置拉取、解析、反序列化的动作推迟到首次 GetConfigCache("xxx") 或 viper.Get("key") 调用时才做。底层依然依赖 sync.Once + 接口抽象。
以 Agollo 为例：
- 初始化 client 时只建 HTTP 客户端、注册监听器，不拉任何命名空间数据
- 调用
client.GetConfigCache("database")才触发对应 namespace 的首次拉取与缓存填充 - 如果某命名空间从未被访问，它的配置内容就永远不会被加载进内存
这种模式对微服务特别实用：一个服务可能声明支持 10 个命名空间，但实际只用其中 2–3 个，其余完全静默。
真正容易被忽略的是：延迟加载不等于零成本。首次调用仍要走网络、解析 JSON、构建结构体——只是把延迟从启动阶段挪到了业务请求阶段。你需要在日志或 trace 中明确标记这些“首次加载点”，否则线上排查超时会很困惑。
