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 行。
