go 1.17+ 的 module 懒加载解决的是“不该加载的依赖被强制引入”问题，通过构建时依赖图修剪，仅保留实际 import 路径涉及的 module，避免幽灵依赖干扰构建与 tidy。
Go 1.17+ 的 module 懒加载到底解决了什么问题
它解决的不是“要不要加载”，而是“不该加载的别硬塞进来”。在 Go 1.17 之前，只要某个 module 出现在依赖图里（哪怕只被一个未被构建的 package 引用），go build 就会强制要求它存在、可解析、版本可验证——哪怕你压根没用到它。这导致：go mod tidy 后 go.mod 里挤进一堆“幽灵依赖”，go list -m all 输出冗长，CI 构建因无关 module 缺失或校验失败而中断。
module graph pruning 是懒加载的前提
懒加载生效前必须先做依赖图修剪（pruning）。Go 编译器会静态分析所有 import 语句，只保留真正参与构建路径的 module 节点。关键判断依据是：该 module 中是否有至少一个 package 被当前构建目标直接或间接 import。
- 如果
module c只被module a的未使用包y引入，而构建时只 import 了a/x，那么c就会被剪掉 -
go mod graph显示的是完整依赖关系，但go build实际只走修剪后的子图 - 修剪发生在
go build阶段，不是go mod tidy阶段；tidy仍会保留在go.mod中的 indirect 依赖（除非手动清理）
懒加载对开发者日常操作的真实影响
它让本地开发和 CI 更健壮，但不会自动帮你删代码。几个典型场景：
- 你 fork 了一个 SDK 仓库，并 patch 了其中某个不相关的子模块，但主项目只用它的核心包 —— 现在你不用再为那个 patch 模块维护
replace规则 - 团队共享一个 monorepo，不同服务各自依赖不同插件模块，构建单个 service 时不会因其他 service 的废弃依赖报错
-
go test ./...不再因为某个测试文件里注释掉的import _ "example.com/unused-driver"而失败（前提是该 driver 没被任何实际执行路径引用）
注意：懒加载不改变 go mod vendor 行为 —— vendor 仍会拉取 go.mod 中声明的所有 module，不管是否被修剪。
容易被忽略的边界情况
修剪只看 import 路径，不看运行时逻辑。以下情况仍会触发加载：
- 使用
plugin.Open动态加载 .so 文件，其路径硬编码在字符串里，编译器无法静态识别 - 通过反射（
reflect.ImportPath）或go:generate注释动态引入包 - 在
init()函数中调用sql.Register等全局注册，即使对应 driver 包未被显式 import，只要最终二进制链接了它，就仍算“被引用”
真正的懒，是编译期裁剪；不是运行时按需下载，也不是启动时延迟初始化 —— 别把它和 sync.Once 搞混。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
