do不是传统容器，而是基于泛型的轻量级依赖解析器，编译期绑定类型、运行时零反射、无字符串映射表，不支持遍历或按名查找，仅通过Provide/MustInvoke等泛型函数实现类型安全注入。
直接说结论：do 不是传统意义上的“容器”对象，它本质是一个轻量级的泛型依赖解析器，所有服务注册和解析都基于类型参数 [T] 在编译期绑定，运行时零反射、无 map[string]interface{} 类型擦除 —— 这意味着你不能像操作 map 那样动态查 key，但换来的是类型安全和性能。
为什么 do.New() 返回的不是可遍历容器？
do.Injector 是一个接口，底层不维护服务名到实例的字符串映射表。它只记录「谁提供了 T」和「T 依赖哪些其他类型」，靠泛型函数（如 Provide[T]、MustInvoke[T]）在编译时生成类型专属的解析路径。
- 你无法用
for range遍历已注册的服务，因为没有公开的枚举方法 - 没有
GetByName("xxx")这类 API，命名服务必须用ProvideNamed[T]+MustInvokeNamed[T]成对使用 - 调试时想看当前有哪些服务？只能靠 IDE 跳转或手动 grep
do.Provide调用点
Provide 和 ProvideNamed 的关键区别在哪？
两者注册逻辑完全不同：前者靠类型推导服务标识（inferServiceName[T]()），后者显式指定名称字符串，且该名称会参与类型约束检查。
-
Provide[T](injector, NewX)：要求NewX返回值类型必须严格匹配T；若T是接口，NewX必须返回实现该接口的具体类型 -
ProvideNamed[T](injector, "db", NewDB)：允许同一类型T多次注册，只要名字不同；但后续必须用MustInvokeNamed[T]("db")显式指定名称获取，否则报错 - 混用风险：若你先
Provide[*sql.DB]，又ProvideNamed[*sql.DB]("primary")，它们互不影响，但MustInvoke[*sql.DB]只能拿到第一个注册的实例
服务初始化失败时，MustInvoke 和 Invoke 哪个更可控？
MustInvoke[T] 是 panic 版本，适合启动阶段强依赖；Invoke[T] 返回 (T, error)，适合需要降级或重试的场景。
立即学习“go语言免费学习笔记（深入）”；
- Web 服务启动时，数据库连接、配置加载等关键依赖建议用
MustInvoke，让进程快速失败，避免带病运行 - 非核心依赖（如第三方通知服务、缓存客户端）建议用
Invoke，捕获 error 后可 fallback 到默认行为 - 注意：
MustInvoke的 panic message 默认只含类型名，调试困难；可在提供函数里提前校验并 panic 带上下文信息，例如if db == nil { panic("failed to open DB: " + err.Error()) }
作用域（Scope）实际怎么隔离服务？
Scope 不是独立容器，而是对 Injector 的克隆 + 局部覆盖。子作用域可以覆盖父作用域中同类型的注册，但无法修改父作用域已解析的实例。
- 调用
injector.Scope()得到新Injector，它继承父作用域所有服务定义，但注册新服务不会影响父作用域 - 常见误用：在 HTTP handler 中为每个请求创建
Scope并Providerequest-scoped service（如*http.Request），但忘了在 handler 结束时调用scope.Shutdown()—— 若该 service 实现了io.Closer或自定义Shutdown()，资源会泄漏 - 真正隔离的关键是「类型唯一性」：只要子作用域注册了与父作用域相同类型
T的新 provider，MustInvoke[T]就会走子作用域路径，无需额外标记
最容易被忽略的一点：泛型类型参数必须完全一致才能命中。比如 type UserService interface{...} 和 *userServiceImpl 是两个类型，Provide[UserService] 和 Provide[*userServiceImpl] 注册的是不同服务，MustInvoke[UserService] 拿不到后者，哪怕后者实现了前者 —— 这不是 bug，是泛型设计的必然结果。
