延迟加载指服务实例在首次Resolve或Invoke时才执行构造函数，注册必须在启动期完成；do框架默认延迟加载，需用泛型参数显式声明类型；GoLobby需显式Lazy绑定且不支持依赖注入；手写容器需注意nil检查、类型匹配、导出字段及并发安全。
延迟加载依赖注入容器的核心判断
Go 语言没有运行时自动扫描或注解驱动机制，所谓“延迟加载”不是等用到才注册，而是指服务实例在首次 Resolve 或 Invoke 时才真正执行构造函数——注册动作本身必须在启动期完成。混淆这点会导致 panic 或静默失败。
do 框架中如何启用延迟加载
github.com/samber/do 默认就是延迟加载：调用 do.Provide 只是把工厂函数存进注册表，不执行；直到第一次 do.MustInvoke[T] 才调用工厂函数并缓存结果。
- 必须用泛型参数
[T]显式声明目标类型，否则无法从注册表中匹配到对应工厂 - 工厂函数签名必须是
func(*do.Injector) (T, error)，返回值类型要和泛型一致（*Service≠Service） - 如果工厂函数内部依赖其他服务，要用
do.MustInvoke[Other](i)获取，不能直接传参——因为i是当前 injector 实例，保证了依赖图解析顺序 - 避免在工厂函数里做阻塞操作（如
sql.Open），否则首次调用会卡住整个请求流
GoLobby/Container 的延迟绑定写法
github.com/golobby/container/v3 需显式使用 Lazy 绑定才能启用延迟加载，普通 Singleton 或 Transient 是立即执行的。
- 写法：
container.Lazy(func() DBService { return &DBService{...} }) - 注意它不接受
*Injector参数，所以无法做依赖图解析——所有依赖必须在工厂函数内手动 resolve 或传入闭包 - 若需依赖其他服务，得先
Resolve出来再传给工厂：container.Lazy(func() Service { db := new(DBService); container.Resolve(&db); return &Service{DB: db} }) - 这种写法容易漏掉错误检查，建议包装成带
error返回的函数并用MustResolve替代裸调用
自己实现延迟加载的关键陷阱
手写容器时最容易在反射调用处崩溃，核心是没处理好 nil 指针和类型匹配。
-
reflect.Value.Interface()在字段为nil *sql.DB时直接 panic，必须先检查v.IsValid() && !v.IsNil() - 泛型类型注册要用
reflect.TypeOf((*Repository[User])(nil)).Elem()作 key，不能用字符串或未实例化的Repository[T] - 结构体字段必须导出（首字母大写），否则
v.Field(i).IsValid()返回 false，反射拿不到值 - 并发场景下，首次加载和后续读取需加锁，或用
sync.Once包裹初始化逻辑，别依赖 map 自带的读安全
真正难的不是“怎么推迟执行”，而是确保推迟之后那一瞬间，所有依赖都已注册、类型完全匹配、指针非空、且能被反射安全访问。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
