Go 1.17+ 的 module graph pruning 是懒加载的前提，即构建阶段仅解析实际被 import 的依赖路径，跳过未使用的间接依赖（如未引用的 package y 及其依赖 module c），从而减少下载与分析开销。

Go 1.17+ 的 module graph pruning 是懒加载的前提

Go 模块的“懒加载”不是运行时按需加载代码，而是构建阶段对依赖图的精简——go build 不再强制解析和下载所有间接依赖，只处理实际被 import 的路径。这依赖于 Go 1.17 引入的 module graph pruning（依赖图修剪）机制。

典型现象：你项目里 import "example.com/a/x"，而 example.com/a 的另一个包 y 依赖了 example.com/c，但你的代码完全没用到 y。在 Go 1.16 及之前，go mod download 仍会拉取 c；从 Go 1.17 起，只要 c 没被主模块直接或间接引用，它就不会进入构建流程。

• 必须启用 Go modules（GO111MODULE=on），且 go.mod 中不能有 // indirect 标记的“幽灵依赖”残留
• 修剪只发生在构建时，go list -deps 或 go mod graph 仍会显示完整图谱，别被误导
• 若某间接依赖被 _ 导入（如 import _ "example.com/c"），它会被视为“有副作用”，不会被修剪

lazy module loading 不等于 runtime lazy loading

Go 官方文档里说的 “lazy module loading” 容易让人误解为类似 JS 的 import() 动态加载。实际上，Go 不存在运行时模块加载——所有代码在编译期就已确定并打包进二进制。所谓“懒”，仅指构建工具链在解析依赖时跳过未使用的子树。

这意味着：

• 无法在程序运行中动态加载新模块或替换已有包
• go run main.go 第一次执行时仍会触发完整的依赖解析（包括修剪），后续缓存才加快速度
• 如果你用 replace 或 require 显式声明了某个模块，即使没用到，它也不会被修剪

对比 sync.Once 懒初始化：完全不同的层级

Go 语言里常被一起讨论的“懒加载”，还有 sync.Once 实现的运行时懒初始化（比如数据库连接、配置加载）。这两者毫无关系，但容易混淆：

• sync.Once 控制的是单个函数在运行时最多执行一次，属于值/资源级惰性求值
• module 懒加载是构建系统的行为，影响的是编译前的依赖获取与分析范围
• 一个服务可以同时用：go mod 修剪掉不用的第三方模块 + sync.Once 延迟初始化 DB 连接
• 错误示范：试图靠 module 懒加载来避免启动时初始化开销——它不解决这个问题

真实性能收益取决于项目结构而非版本号

升级到 Go 1.17+ 并不自动带来显著加速。收益大小取决于你的依赖拓扑：

• 依赖树宽而浅（大量 direct dep）、但实际只用其中几个子包 → 修剪效果明显，go mod download 时间下降 30%~50%
• 依赖树窄而深（少数强耦合模块）、且所有路径都被 import → 几乎无修剪空间，构建时间变化不大
• CI 环境中频繁清理 $GOCACHE 和 $GOPATH/pkg/mod 时，修剪带来的网络节省更可观

最容易被忽略的一点：go list -m all 仍会列出所有模块（含被修剪的），但 go build -v 的输出里看不到它们被 fetch 或 build —— 别只看列表，要看实际日志里有没有 Fetching 行。