Go 1.17 的 module graph pruning 和延迟加载不感知泛型，但可用泛型封装按需初始化工具：工厂函数须返回指针以避免提前实例化，依赖需隔离在独立 package，Loader 接口应抽象行为而非具体类型，且泛型包禁用 init 函数和构建约束干扰。
Go 1.17 引入的 module graph pruning 和延迟加载机制，本身不感知泛型——泛型在编译期完成特化，而延迟加载发生在构建阶段（go build 或 go run 时按需解析 import 路径）。但你可以用泛型封装一套“按需初始化”的工具，让模块依赖更清晰、实例创建更可控。关键不是“泛型触发延迟加载”，而是“用泛型避免提前实例化 + 配合 module 修剪规则，减少无用依赖传播”。
泛型工厂函数必须返回指针，否则无法规避初始化副作用
泛型类型参数在编译时展开，但如果工厂函数返回值是值类型（比如 func New[T any]() T），调用时会强制构造该类型的零值——哪怕你根本不需要它。这会导致：
- 嵌套结构体字段的初始化逻辑被执行（如
sync.Once、http.Client构造） - 包级变量被提前触发（尤其是带 init 函数的第三方库）
- 即使该泛型实例最终未被使用，也会因调用链存在而阻止
module graph pruning
正确做法是只返回指针，并配合 lazy.New[MyDB]().Connect() 这类链式调用：
func New[T any]() *T {
var t T
return &t
}
注意：这个 New 不做任何实际构造，只是占位；真实初始化应放在方法里（如 Init()、Open()），且这些方法不应出现在包导入路径中（即不能被 import 直接触发）。
立即学习“go语言免费学习笔记（深入）”；
延迟加载依赖必须隔离在独立 package 中
Go 的 module graph pruning 只对未被任何构建路径引用的 module 生效。如果你把泛型工具和 heavy 依赖（比如 github.com/xxx/orm）写在同一 package，即使你只用泛型部分，整个 module 仍会被保留。
实操建议：
- 新建
pkg/lazy，只放泛型工厂、Loader接口、LoadFunc类型定义 - 把具体实现（如
postgres.NewClient）放在pkg/adapters/postgres，并确保该目录下没有其他 package import 它 - 主程序只 import
pkg/lazy，并在运行时通过func() interface{}匿名函数加载具体实现
这样，当 go mod graph 分析时，pkg/adapters/postgres 所在 module 若未被任何 .go 文件直接 import，就会被自动修剪掉。
泛型 Loader 接口要避免暴露具体依赖类型
不要写成：
type Loader[T *sql.DB] interface {
Load() T
}
这会让 T 成为接口约束的一部分，迫使调用方显式传入 *sql.DB，从而在编译期绑定具体依赖，破坏延迟意图。
应该用抽象行为代替具体类型：
type Loader interface {
Load() (any, error)
}
<p>func Register[T any](name string, fn func() (T, error)) {
loaders[name] = func() (any, error) {
v, err := fn()
return v, err
}
}
这样注册时才真正引入具体依赖（比如 Register("db", postgres.New)），而泛型工具层始终与 postgres 零耦合。
容易忽略的坑：go:build 约束 + 泛型组合会干扰 module 修剪
如果你在泛型工具里用了 //go:build !test 这类构建约束，又在测试文件中 import 了该泛型包，那么即使生产代码没用到，整个 module 也可能因测试依赖被保留在 go.mod 中。
检查方式：
- 运行
go list -deps ./... | grep your-module-name，确认是否只有预期路径引用它 - 删除所有
_test.go后再跑go mod graph | grep your-module，看是否还存在边 - 泛型工具包禁止含
init()函数或包级变量赋值（哪怕只是var _ = fmt.Println）
泛型本身不延迟，但它是目前最干净的“延迟执行契约载体”——只要你控制好初始化入口点、隔离依赖边界、不泄露具体类型，就能让 module 修剪真正起作用。
