Go 1.17 的 lazy module loading 是构建期依赖图裁剪，非运行时懒加载；它静态分析 import 路径，仅保留实际被引用的 module，剔除未使用的间接依赖（如 module C），发生在 go build 等命令中，不影响运行时行为。
Go 模块本身没有“懒加载”这个运行时机制，go mod 的 lazy module loading 是编译构建阶段的依赖图裁剪行为，不是程序启动后按需加载代码——这点容易误解，得先划清边界。
Go 1.17 的 lazy module loading 到底指什么
它指的是构建时对 module 依赖图的静态分析与裁剪，而非运行时动态加载 .so 或延迟解析 import。核心是：只保留真正被代码引用的 module 路径，剔除未被直接或间接导入的 module（哪怕它们出现在 go.mod 的 require 中）。
- 触发条件是项目中存在未被任何
.go文件实际 import 的 module；比如module c只被module a的某个未使用的包y引用，而主模块只用了a的x包 —— 那么c就可能被裁掉 - 裁剪发生在
go build、go list、go mod graph等命令执行时，由 Go 工具链自动完成，开发者无需手动开关 - 裁剪后，
go mod tidy不会把被裁掉的 module 从go.mod中删掉，但go mod vendor也不会把它们拉进vendor/ - 错误现象：
go build成功，但go mod graph输出里看不到某些 require 的 module —— 这不是 bug，是 lazy loading 生效了
为什么不能靠它实现运行时资源懒加载
lazy module loading 和 sync.Once 完全不相干：前者发生在构建期，后者作用于运行期。想让数据库连接、配置解析等逻辑延迟到第一次调用才执行，必须用 sync.Once.Do，而不是指望 go mod 帮你“懒”。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 常见误用：以为把某个 heavy 的 module 放在独立子包里，再按需 import，就能“懒加载”——实际上 Go 编译器仍会在构建时解析整个 import chain，只要路径可达，就计入依赖图
- import 语句本身是编译期行为，不存在“运行时才 import”这回事；
_导入或条件编译（//go:build）才能真正规避构建期加载 - 如果真想模拟运行时加载，只能用
plugin包（受限于平台、不支持跨平台、无法热更新），且和 module 机制无关
sync.Once 和 module lazy loading 容易混淆的点
两者都带“lazy”，但作用域、时机、机制全不同。混淆会导致设计错位：比如把初始化逻辑塞进一个独立 module 里，以为能靠构建裁剪来控制执行时机，结果发现变量早被 init 函数执行了。
立即学习“go语言免费学习笔记（深入）”；
-
sync.Once必须绑定到具体变量上（如结构体字段或包级指针），Do调用才触发；它的“懒”是函数执行层面的 - module 的 lazy loading 是工具链对
go.mod和源码 import 关系的静态推导，不涉及任何 Go 代码执行 - 一个 module 被裁掉 ≠ 它的 init 函数不会执行；只要该 module 被任一已保留路径 import，init 就会在 main 启动前跑
- 真正影响运行时行为的，永远是代码执行流，不是 module 名字是否出现在
go.mod里
最常被忽略的是：module 裁剪只看 import 路径是否可达，不看代码分支是否被执行。哪怕你用 if false { _ = "example.com/heavy" }，只要 import 语句存在，module 就算“活跃”。运行时的懒，还得靠 sync.Once 自己写清楚。
